Slashdot Mirror
How Free is BIND 8.2?
Bun writes "It looks like one of the foundations of the Internet may no longer be truly "Open Source". Apparently, the license restrictions on BIND 8.2 do not meet the Debian Free Software Guidelines (DFSG). Check out the Linux Weekly News for details.
"
(Not that it was ever valid in Europe, anyway.)
The non-free code is mixed in with the free code ATM, such that creating a version of BIND that uses only free software is non-trivial. However, I believe that this is being undertaken by the ISC.
I'm definitly throwing some sort of party on September 20, 2000. I missed my chance when the Diffie-Hellman patent expired.
--
Xenu loves you!
A lot of people are bringing up DENTS. It's an alternate DNS implementation, dedicated to remaining 100% Free Software, and it's technically superior too! Take a look, it's a really cool project. It's important to have another Free Software alternative to BIND, even if BIND is itself Free Software, just because DNS is so critical to the entire Internet.
It's a mistake to put proprietary elements in IETF standards (and non-IETF standards as well). If RSA isn't willing to open this up, we're just going to have to develop an alternative to the standard (which is already in progress) and a way to gateway between the two standards.
And last, this is one of the more mature Slashdot discussions concerning Open Source that I've seen in a while. Good going, folks!
Thanks
Bruce Perens
Bruce Perens.
If you havn't looked at Dents yet, you should. It's a nifty modular DNS server. And, AFAIK, there is no "non free" code.
Nothing to worry about.. move along now... ;)
--
I just want to thank the Debian developers for keeping on top of issues such as this. I think that it's great that we have distributions like Redhat that are willing to stick to the GPL for their own software, but if the Community is going to stick to their roots we really do need *some* sort of organization to keep track of who is and who is not playing by the rules.
I'm also looking forward to Debian's next package freeze, due to take place on Nov. 6th...
Your Brain + EEG + LEGO Robots = Brainstorms
The only problem is with the included RSA code, so we can fix it in 9/2000 when the RSA patents expire.
> modularizing the thing Yes, that's the plan.
Authentication is authentication (well, there are two methods - the standard and Microsoft's :) ). The same authentication mechanisms can be applied to a zone transfer or an update (or even a normal query), since the authentication applies to the full DNS message and is based on the identity that sent the request.
Yes, RSA does encryption. It also can be used for authentication, but not exactly in the way you describe.
An entity holds a public/private key pair. When sending a message, it generates a hash or digest(MD5, SHA1, etc), and applies the algorithm to the hash using its private key. This creates a digital signature which is sent along with the message. The public key is widely disseminated. Therefore, when the message and signature are received, the receiver can compute the message digest and use the RSA public key to prove that the signature is valid.
This is not useful for encryption, since the message is sent in the clear, and cannot be obtained from the digital signature alone. This is how DNS Security works - KEY records store public keys in DNS, and SIG records contain digital signatures.
whether suddenly the Debian Free Software Guidelines are considered the
de facto standard for what can be considered open source software. I do
realize that it is the basis for being able to claim the official
"Open Source" mark. But I fear that throwing up this argument against
some services might be counterproductive. Face it, not everyone is going to agree to the DFSG, for whatever reasons.
Does that mean we should not accept things people like that write? Or should it not be acceptable to be used for
the general workings of something so complex and pretty much anarchy-based as the Internet?
Sorry, but I do not agree. I feel that being reasonable on both sides is better than not. I really do not feel that allowing e.g. modular approaches to be able to not use proprietary parts would be sufficient to cover danger areas.
And perhaps let's give ISC the chance to try to rectify the situation in such way that all parties are sufficiently cared about.
There is a reason why often commercial compilers perform better than GCC - not using that advantage is sometimes plain silly.
Zone transfers aren't secured in this respect. Data within a zone is cryptographically signed, so that you can be sure that it really is valid, and someone hasn't been able to spoof you, etc....
o nfig/trusted-keys.phtml to learn more about DNSSEC and how it works.
This way you can also be sure that when you ask for "fred.yourzone.org" and the answer is that the next valid label is "george.yourzone.org" that not only does "fred.yourzone.org" not exist, but that there are no other labels that exist between that and "george.yourzone.org", so "frederic.yourzone.org" doesn't exist (and you don't need to ask about it), nor does "fredbert.yourzone.org" (and you don't need to ask about it either), etc....
The zone transfers are secured in the same way they always have been -- by the authoritative nameservers restricting what IP addresses it will respond successfully to AXFR (or IXFR) queries.
Follow the links from http://www.isc.org/view.cgi?/products/BIND/docs/c
Brad Knowles
http://daily.daemonnews.org/ -- if you're not
Yes, but due to the DNSSEC spec, alternate signatures do not interoperate. Also, DSA & DH are much, much slower than RSA. There is a reason the IETF chose RSA as the RFC "recommended" algorithm...
We would have prefered to not use code from RSADSI (it isn't RSAREF, it is DNSsafe -- they are different), however given RSA is the recommended algorithm in DNSSEC and RSA is patented, our choices were a bit limited.
The patent will expire next year, so if BIND insist on shipping this non-free code I hope they will undertake to replace it with FREE code next year
As as been referenced elsewhere, we will be creating a BIND-NORSA distribution for those who find the DNSsafe license objectionable.
No, their version of DDNS conforms to the RFCs. What is unique to Microsoft if their mechanism for secure dynamic updates. They use GSS-TSIG which is non-standard (but for which they have written an IETF Internet-draft). The problem is that to interoperate with Win2K, GSS-TSIG requires a GSS-API implementation that conforms to Microsoft's unique implementation of GSS-API. Unfortunately, it does not appear that Microsoft has provided enough information to create an interoperable GSS-API implementation.
Dynmic DNS not making it into BIND till the new version
No, BIND has had DDNS for 3 years. What was new to 8.2 was DNSSEC which provides security with public key cryptography (TSIG uses private key crypto) and is thus much more scalable (at least in theory). The problem is that the IETF chose RSA for the "recommended" signing algorithm (for good reasons) and RSA is patented. ISC negotiated a fairly liberal license but the Debian folk do not consider it liberal enough.
a new dynamic dns is unnessary in most cases, and could be done fine with dhcp+a few scripts
You can do this now with BIND 8, albeit not securely. 8.2.2 (due out real soon now) will have the ability to do secure dynamic update with the IETF standard TSIG (not Microsoft's GSS-TSIG).
The problem (which may or may not be a problem, depending on your environment): you won't be able to interoperate with Win2K.
Indeed they can. Given the (IMHO) poor operational design of DNSSEC, they undoubtedly will be, particularly after we gain a bit of operational experience with the current DNSSEC protocol. However, the current proposed standard DNSSEC specification states that RSA is the recommended algorithm. ISC prefers to implement standards as opposed to (say) Microsoft which invents their own.
All it takes is publication of draft and going through usual process until it becomes RFC.
I gather you haven't been involved in the IETF much. It is a bit more involved than that...
To clear things up... RSA is encryption. It involves use of exponentials, and at the risk of national security, here is how it works:
Pick two big primes (p and q) and multiply them together to get n. Next, find two numbers, e and d, such that e*d === 1 mod n. This means that (a^e)^d == a and (a^d)^e == a all mod n. You then public your public key: e,n. You remember your private key: d. p and q remain private forever and are best forgotten.
The reason RSA is used for authentication is because it does have an overhead because you are running modular arithmetic on 512 (or more) bit numbers. This is how authentication works:
Same setup as before (p,q->n; get e,d)
The challenger holds your public key (e,n) and sends you an unencrypted message, m. You send back m^d === c mod n. The challenger can verify your identity by raising c^e mod n, and comparing this to m.
This operation only has to be done once, so it is relatively efficient for the security it provides. When setting up a secure connection, you can use RSA to authenticate someone and then to transmit a less secure session key. This session key isn't as secure, but it arrived securely. This is done for efficiency, and one can argue that it is an insecure model.
-B
ps. All this info is available from the books and from the source to many encryption products (ssh for instance)
After all, the patents expired on it and GPG uses it right now (besides, I've heard that it's better than RSA anyhow...)
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Is the Open Source community strong enough yet to overturn a bad standard in such way?
--- Hindsight is 20/20, but walking backwards is not the answer.
Still, the software wouldn't be 100% free anymore. The RSA code would be like a source code comment if it is switched off and I don't think you can put non-open source-licensed commentary into an open-source program.
But shouldn't modularizing the thing, leaving only hooks for the RSA module in BIND, work fine?
The BIND people are like most old-school BSD groups, their number one aim is to get high quality working software to as many people as possible. They will accept any license as long as it includes free redistribution in some form.
That's fine -- but it doesn't mean that what's good for them is good for Free Software. For Debian, and other free software projects the number one priority must be to keep software Free.
Two other points while I'm here (1) Outside the USofA there are BETTER, FASTER, and MORE FREE implementations of the RSA algorithm. No-one outside the BIND group wants the awful RSAREF code. (2) The patent will expire next year, so if BIND insist on shipping this non-free code I hope they will undertake to replace it with FREE code next year.
Nick.
RSA is not used for encryption; DNS doesn't do encryption. RSA is not used for securing zone transfers, it's used for generic data authentication, as specified in the DNS Security RFCs. The other alternative is DSA, which is the required algorithm, but RSA verifications are approximately 60x faster, which makes a pretty big difference. A different implementation of RSA cannot be used, because of patent issues. Export control is not an issue, since RSA is only used for authentication.
It looks like the only option is to optionally remove RSA support, which (fortunately) wouldn't be too difficult.
There is absolutely nothing wrong with a company puting restricitons on the use of software they have developed. Nothing at all.
However, including non-free software as an integral working part of a free software package defeats the purpose of having a free license in the first place. It severely cripples the freedoms granted by the free license. If one is to do that, then why not make the whole license non-free?
In closing, I see nothing wrong with having non-free license software or free license software as long as the two are not fundamentally interdependant. Once the licenses are mixed, freedom is lost.
The Open Source Definition is pretty much the same as the Debian Free Software Guidelines, both by Bruce Perens, so if it doesn't meet the standards of one it won't meet the standards of the other. However I'm sure it'll soon meet both. And widespread use of DNSsec would be an *excellent* thing.
--
Xenu loves you!
As I understand it, the problem here is that you can't seperate the RSA code from the rest of the BIND code and redistribute it; you can only use it with BIND.
So what?
Is it so horrible that a company is giving away something that they developed, but that they don't want people spreading it around other than for the purpose they envisioned it for? They don't even say that you can't modify it, only that they retain the rights to incorporate your modifications.
RSA's solution works, and it is free to use, even if it's not as free as some would like. I fully support open source and free software, but I also respect that some people or companies want to retain some forms of control.
Is this a special case because it involved a piece of software that is crucial to the operation of the internet? I don't know. If it becomes a real issue in the future, then a solution can be found, but it seems that people are only making a stink about it right now because it's not 100% absolutely, completely free for everyone to use however they want. In other words, open source zealotry.
I'm sorry if I sound negative about this, but I get frustrated when people get upset about a piece of free software because it's not licensed exactly the way they want. To quote an American expression, 'Why look a gift horse in the mouth?'
Instead of trying to re-invent something that works and is free to use, why not just move on and tackle other issues?
When RSA asked if their code could become the de-facto standard for protecting AXFR and IXFR transfers in Bind 8, they were told they would have to offer up a completely free version with "no restrictions whatsoever", including export restrictions from the U.S. and no EULAs or patent/copyright problems. See comp.protocols.domains.* in dejanews for a long history of the discussion.
:-) and following the issues.
There was a lot of talk at the time about whether the RSA code was truly free. General opinion was that it was not, but people have been using the code and just shrugging it off. Others preferred PGP or similar variations, but the strong crypto meant the ISC couldn't make the source available for free anonymous download. But the majority of voices wanted only one standard, since this stuff is pretty complex and having to support PGP/RSA/BlowFish/Joe'sXORhack would have been a nightmare.
Now I expect some clients to start asking me about this, since I tend to put the latest Bind in every project I build. Seems that every client site I've been on, the techies all start reading slashdot
the AC
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
The problems are being worked out.
The reason it is going to have problems is because
they are adding RSA into the newer version to
allow security transfers of zone files.
They are trying to add an option to have no rsa
as a build option.
> Why didn't the BIND folks use Diffie-Hellman
> instead? Couldn't this section of BIND be
> rewritten to use Diffie-Hellman?
Well, it could be, but D-H is broken. (See Schnier's _Applied_Cryptography_ for details.) The D-H patents only mattered (until they expired) because they applied to all future, better ways of doing the same thing. (Because that's what patents protect.)
> How is it that you are allowed to export the
> source code for RSA as long as you intend to use
> it for authentication?
Because that's the law. (Well, Federal Regulation, actually, but enforced as law.) Encryption code used only for authentication and not actually for encryption (ie, digital signature-only stuff) is 100% exportable. (Read Schnier for more, again.)
Of course (not that there's really any 'of course' about it), you can pretty much turn any digital signature software into data encryption. So it really doesn't make much difference.
> Can I export a cruise missle to Libya as long as > it's intended to be used as a lawn ornament?
Depends how much the Lybians contribute to the next presidential campaign. (Hey, it worked for the Chinese!)