Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
The Internet

How Free is BIND 8.2? 86

Posted by Roblimo from the keepers-of-the-free-software-flame dept.
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. "
This discussion has been archived. No new comments can be posted.

How Free is BIND 8.2? More

How Free is BIND 8.2?

Comments Filter:

  • Re:Hold up! (Score:1)

    by Anonymous Coward
    Think about it... I convince your name server that client.com resolves to my box. Next time you try to telnet to client.com, I get your password. Of course ssh defeats this, etc., etc., but there are plenty of inventive things you can do if you can convince people that they're talking to someone trusted when they're really not.
  • Yes, Dents [dents.org] is a replacement for BIND. It is currently in active development.

  • Because ElGammal isn't an IETF specified algorithm for DNSSEC. ISC tries to conform to the RFCs as much as possible.

    Specs can be changed. All it takes is publication of draft and going through usual process until it becomes RFC.

  • 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.
    Sure, some people will disagree with the DFSG. Those guidelines are there to draw a line between free software from unfree software (at least in the Debian organization's eyes). You could reasonably draw the line in a lot of different ways. So why not compromise when something potentially advantageous is just a little over the line?

    But if you compromise the line will keep being drawn on the other side of more and more restrictive licenses. Do we consider BIND free on the whole, even if a piece of it isn't? Do we consider the old Qt license free because anyone making free software can use it? Do we consider the Sun Community Source License free because you can read the source code? Do we consider Explorer free because anyone can download it off the Internet?

    The Golden Median is dumb -- the middle is only dependant on what you consider the edges to be. And if you allow the edges to be redefined then you'll just drift, controlled by whoever does the defining -- Security Dynamics?

  • Close but no cigar.

    If it did in fact say "everyone else", then it would be close to an open source license. Since it _does_ say "RSA Data Security" it is exactly the opposite of an Open Source License.
  • drc@isc.org writes:
    >I find it unfortunate that ISC is put into the
    >position of being either standards conformant
    >xor "free" according to the Debian folks.

    I think it's unfortunate that software patents have to put Debian or ISC into this position.

  • But shouldn't modularizing the thing, leaving only hooks for the RSA module in BIND, work fine?

    Yes. This is one of the options being discussed.

    Additionally, I'd like to point out that DNSSEC does not depend on RSA; other signature systems (DH and DSA) are possible too.

  • The reason RSA is being used for signatures is that it is more than 10-40 times faster than DSA or other similar methods when you do signature verification, moreover, DSA signature verification gets a lot slower as the modulus increases compared to RSA. This is due to the nature of the math used and no one has found a suitable alternative to RSA which provides the same security and comes even close to RSA in verificiation speed. This is an important feature because people will be doing a lot more verifications of DNS records than they will do signatures.
  • Which is one reason why many of the domains that I help set up have a bind server as the master, and dents as one of the slaves... The first rule in failover is not to use same technology on the "backup" system so that a failure on the primary does not also affect the secondary...



    https://www.mav.net/teddyr/syousif/ [mav.net]
  • Windows 2000 uses TSIG and Kerberos for update authentication according to Paul Leach, who works for Microsoft.

    Is there a difference between authentication for zone transfers and authentication for single IPs?


  • Surely the only problem is one of patents, not copyrights. But we already have 'free' software which is restricted in the US and Japan by patents, and some licenses (eg IBM's licence for Jikes [ibm.com]) restrict your use of certain patents, while the software itself is still considered free. (It is at least free in Europe, but maybe not for much longer; see freepatents.org [freepatents.org].)
  • The Linux Weekly news article states:
    The DNSsafe software cannot be used or distributed separately from the BIND software. You only have the right to use it or distribute it as a bundled, integrated product.

    which violates several points of the DFSG, in that it restricts distribution of the software;

    Surely this is incorrect. If it were correct then it would follow that the QPL license was not DFSG compliant, since the QPL also does not permit distributing any (strict) subset of the QPL'd source code. But this is a contradiction as the QPL has been declared DFSG compliant.
  • I noticed the same thing. The Open Source Definition has an extra clause, 10, that gives examples of licenses that meet the definition.

    The other more important difference I noticed is the the OSD specifically prohibits obsfucating the source code (see clause 2), while the DFSG does not.

    Leaving us in the rather odd position in which open source software (in the OSD sense) is actually "more free" than "free software" (in the DFSG sense).

    It's a strange world.
  • Why didn't the BIND folks use Diffie-Hellman instead?
    Couldn't this section of BIND be rewritten to use Diffie-Hellman?

    How is it that you are allowed to export the source code for RSA as long as you intend to use it for authentication? Can I export a cruise missle to Libya as long as it's intended to be used as a lawn ornament?

    I can't imagine how the source code could be written so that the RSA sections couldn't just be ripped out and used for encryption.
  • >Nothing to worry about.. move along now... ;)

    Nothing to worry about, in that a section of BIND that improves it's security in a much needed way can't be included in any free BIND?

    Now it's not as serious as it might be, but it's still pretty bad.

  • Ahh. But they appear to be much slower than
    RSA. Don't know myself. I haven't looked at it
    that much yet.

  • There is absolutely nothing wrong with a company puting restricitons on the use of software they have developed. Nothing at all.

    Agreed, but I'd like to distinguish between software written and a patent-license scheme. patented software is very bad, patented MATH is disgusting.

  • I find it quite amusing that one of the statements in the licence there was some objection to was:

    If you modify the...software itself...you must grant RSA Data Security the right to use, modify, and distribute your modifications....
    Now, if we replace `RSA Data Security' with `everyone else,' we get a statement that's darn close to the key tenet of a popular open source licence....

    cjs

  • the Debian folk do not consider it liberal enough.

    True enough. Sometimes the best you can do is not what everyone would like. But that's RSA's fault, not Debian's (or even ISC's). If they didn't insist on raking in the dough from their patented algorithm (a concept nobody outside the U.S. recognizes), there would be no problem here. And that's the key point here: the blame falls 90% on RSA's shoulders (and the other 10% goes to the IETF, for basically creating a broken standard). I don't know what else the ISC could have done in this situation.
  • I quoted him. That's when I mentioned performance. What I did was add additional requirements.

    Yes, some commercial compilers do perform better than GCC. So what. You weigh your own requirements against what is available. My requirements currently match best with GCC. So I'll use GCC. Sure I could get some performance gains with another compiler, but at the cost of some disadvantages (things that mismatch my requirements).

    Price is one of my requirements. Portability is one of my requirements. Sure, performance is a requirement, too, but it's not the exclusive one.
  • I agree that BIND should have included it since it did become standardized. The problem is not that it was included, but rather the way that it was included. The parts need to be separated in such a way that one can choose to have it, or to not have it. Just switching a flag to not compile it in is inadequate.

    My disappointment was that this was not seen until people started to realize the mistake that was made and complained. But we'll see .... when BINDsansDNSSEC comes out.

    I would prefer that any and every protocol involving things like encryption, authentication, or even compression, be designed so as to allow implementations to be "full" or "partial" with respect to these options. Then when to processes are negotiating their communication, they can simply negotiate what common ground they have with respect to the avaiable options, and proceed accordingly with the best actions (which may be to disconnect if no common ground exists on a certain option and the configuration requires the option be used or to not communicate).
  • You mean they are NOT using message digesting and verifying the signature of the has for the zone transfers? What are they doing? Signing and verifying each and every domain one by one?
  • And what might that reason be?
  • So show me how to download it without downloading the add on and I'll believe you. Use the Preview Button! Check those URLs! Don't forget the http://!

    The fact is, it is NOT an "add on" as you claim. It is a "mingled in". ISC's blunder was failing to recognize that this "infected" the purity of the open source code. Yeah, yeah, I hear they are working on it. But that just proves that the original mistake was made. It would have been easier to make two variants of the package if you had that in mind when actually doing it originally. In that they failed. It's not unlike writing an application for MS Windows and then realizing later you need to port it to UNIX, but you stupidly wrote it using proprietary Win32 calls instead open POSIX calls. Poor planning means more work in the long run.

    My guess is that ISC will have the RSA-free version "done" around 9/2000, and then tell everyone "oh you don't need this now".

    OK, so what alternatives to BIND are there?
  • I would consider that to be a good thing.

    What do you mean by "not interoperate"? Will it just fail to be secure and instead fall back to non-secure methods of zone transfer? Or will it refuse to function at all?

    Choosing a proprietary algorithm is mistake #1.

    Choosing only one algorithm is mistake #2.

    Choosing to make it not function without such an algorithm is mistake #3.

    So clue me in.... how many mistakes were actually made (or do I have to go d/l the RFC and count them myself)?
  • I agree with you that DFSG isn't the only thing there is. A free choice (including to sell your software only in binary form) has to be there for everyone, and everyone should feel free to make that choice. If ISC wants to offer software on a non-open basis, I support that right.

    However, ISC makes the claim to offer software that is free and open. If they had offered BIND both with, and without, the RSA code being part of the distribution, or at least made it easy to delete it (for example, if the subdirectory with that code was missing, it would just configure and compile without it fine and just not have that functionality) then I would have still considered it open software as long as people had the right to delete the RSA part and distribute that much.

    Will they fix it? I'll wait and see. The longer it takes, the more they integrated it into the whole system.

    Do they have to provide some other authentication scheme for secure communications between servers that have the alternate? I don't consider that a requirement. It's fine for my purposes to be able to have the latest fixes to BIND without having DNSSEC.

    As for "there is a reason why often commercial compilers perform better than GCC".... name a commercial C compiler that is available for under $1000 and runs on all the major UNIX platforms (including FreeBSD, AlphaLinux, IntelLinux, and SparcLinux). Use the Preview Button! Check those URLs! Don't forget the http://!
  • So you admit that IETF made a blunder in choosing to integrate a proprietary algorithm in a protocol? I'm disappointed that such a protocol wasn't just ignored until 9/2000.

    As for DENTS, I've never tried it or even looked at it. OTOH, do I really need all those extra features BIND gives me? Or are we all going to be putting up our own root servers soon because of the DNS and domain takeover wars that big corporations seem to be masterminding?

    Actually I do run my own root server. Doing that lets me toss in a few hundred extra top level domains. And I don't miss slashdot.org at all because I still point to the usual servers for com/edu/mil/net/org, etc, anyway.
  • > And why weren't you there to celebrate the
    > expiration of the Diffie-Hellman patents with
    > the rest of the DC Cypherpunks, and other
    > luminaries such as Whitfield Diffie himself and
    > Peter G. Neumann? ;-) ;-)

    Er, I was there, Brad. :-)
  • I don't understand. The older versions of BIND work fine, and they're still perfectly free. They will always be free because free software cannot be made non-free. Only derivatives of (BSD and similarly licensed) free software can be made non-free.

    All in all, this seems like a non-issue. The world will go on using the free version, and a few people will use the non-free version. Maybe everyone forgot about a small unpleasantness called X11R6.4.

    sc
  • i believe the BIND crew are coming out with a BIND that does not have the RSA authentication mechanism in it. I dont believe DENTS can conform to the RFCs which require RSA style authentication without falling under the patent issues..
  • > if DSA is considerably slower than RSA, it shouldn't be that big of a deal -- they only need be signed once.

    Signing's not a problem - RSA and DSA are about the same speed. When verifying, though, RSA is much faster (22x faster in the test I just ran).
  • I'm sorry if I wasn't clear enough in my previous post. There is absolutely nothing wrong with anyone choosing a non-free licenses for one's software if that is what one wants. Free and non-free licensed software can peacfully coexist. The only problem is when free and non-free licenses are mixed in such a way that the free license has its freedoms taken away or other wise restricted by the non-free license. If you are going to do so, then there is no point in using a free license.

    One must be careful how one mixes licences, be they free or not.

    So, no, it's not "either accept my freedom or you'll get beaten up." Its not that at all.
  • > Well, it could be, but D-H is broken. (See
    > Schnier's _Applied_Cryptography_ for details.)

    True enough, which is why we have Elgamal. ;-)

    And why weren't you there to celebrate the expiration of the Diffie-Hellman patents with the rest of the DC Cypherpunks, and other luminaries such as Whitfield Diffie himself and Peter G. Neumann? ;-) ;-)


    However, this is just key exchange. We also need a signature standard. Since the keys are being signed off-line, even if DSA is considerably slower than RSA, it shouldn't be that big of a deal -- they only need be signed once.
  • > Well, it could be, but D-H is broken. If it's broken, then is PGP 5.x+ broken as well because if its use of D-H?
  • So show me how to download it without downloading the add on and I'll believe you.

    When we release 8.2.2 final, there will be two versions, bind-8.2.2 and bind-norsa-8.2.2. The difference in the two being -norsa doesn't have the DNSsafe code.

    It would have been easier to make two variants of the package if you had that in mind when actually doing it originally.

    Actually, as there is an interface between BIND and the crypto stuff, it is actually quite easy to drop the RSA stuff out (and in fact, we had already made a version without RSA before due to questions about the exportability of the RSA stuff).

    I find it a bit ironic that the DFSG results in the same solution as the US policy on crypto export...

    My guess is that ISC will have the RSA-free version "done" around 9/2000

    No, 9/1999 (hopefully sooner, depending on how the beta testing goes).

  • What do you mean by "not interoperate"? Will it just fail to be secure and instead fall back to non-secure methods of zone transfer?

    It depends on a site's security policy. If the system is configured to ignore non-secure zones (unlikely, but theoretically possible), then it will not function at all. Of course, there is no way for a client to tell the server it supports DNSSEC...

    So clue me in.... how many mistakes were actually made (or do I have to go d/l the RFC and count them myself)?

    I'd recommend reading the RFC and not relying on the opinion of myself (or others).

  • Because ElGammal isn't an IETF specified algorithm for DNSSEC. ISC tries to conform to the RFCs as much as possible.

  • Re:Dents (Score:1)

    by drc ( 90302 )
    Yes, Dents is a replacement for BIND. It is currently in active development.

    If Dents is going to implement DNSSEC according to the RFCs and expect to interoperate with other DNSSEC implementations, then it will need to support RSA as well. If they do not wish to use DNSsafe under the license provided, they can either risk patent infringement lawsuits or they can negotiate a separate license.

  • Since the keys are being signed off-line, even if DSA is considerably slower than RSA, it shouldn't be that big of a deal -- they only need be signed once.

    Consider the .COM zone. It is over 900 Mbytes (without the NXT records, which will likely kick it up by 30%), increasing about 50Mbytes/week (so I'm told). Consider how often the .COM zone is updated. It is a big deal.

  • And, AFAIK, there is no "non free" code.

    Then it will not interoperate with other sites which use the recommended DNSSEC algorithm (which will most likely be the majority of sites using DNSSEC).

  • The older versions of BIND work fine, and they're still perfectly free.

    They also do not implement DNSSEC. For various reasons, people would like to make the DNS infrastructure stronger and DNSSEC was the method chosen.

  • A lot of people are bringing up DENTS. It's an alternate DNS implementation, dedicated to remaining 100% Free Software,

    Which, of course, it can not be if it implements the DNS as it has currently been specified by the IETF. I find it unfortunate that ISC is put into the position of being either standards conformant xor "free" according to the Debian folks. We are addressing this by creating an additional distribution, one without RSA, and will be working in the IETF to try to come up with a better solution (use of RSA is among the least grotesque warts of DNSSEC from an operational perspective).

    and it's technically superior too!

    I'm a bit confused. DENTS, last time I checked, was at version 0.0.3, was unstable, and had essentially no deployment (understandable, given it is still under development). Yet you claim it is "technically superior". By what measure? Can it handle the 900+ Mbyte .COM zone? Can it sustain 6000+ queries per second? Does it support Dynamic DNS, IXFR, Notify, split DNS, etc.? Vaporware can often be "technically superior" until it has to face an often very unpleasant reality.

    this is one of the more mature Slashdot discussions concerning Open Source that I've seen in a while

    Funny. Wasn't there a bit of an arguably immature flame war resulting from an article in DaemonNews about *BSD being "technically superior" to Linux with no objective criteria?

  • So you admit that IETF made a blunder in choosing to integrate a proprietary algorithm in a protocol?

    No. I believe it made a blunder in designing a protocol that does not allow for reasonable interoperation between multiple algorithms. I detest software patents, but I was given no say in their existance. Given they exist, I believe it appropriate to allow people the choice of using them or not.

    do I really need all those extra features BIND gives me?

    The extensions to the DNS supported by BIND are there because there was an itch that needed scratching and the IETF standardized on the way to do it. As BIND is a reference implementation, it would seem appropriate that we implement those itch scratchers. You are free to not use the features if your particular situation does not require it, however you must admit it is nice having the ability should the need arise.

  • Re:Being worked out. (Score:2)

    by Anonymous Coward
    It's academic anyway. In less than year's time, the patent will have expired.

    (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.
    --
  • IMO Debian is handling this very well and very maturely, their policies are excellent (OK, I wrote some of them but they have done a lot since then), and they are to be complimented for bringing attention to this issue.

    A lot of people are bringing up DENTS [dents.org]. 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

  • Dents! (Score:2)

    by poink ( 7454 )
    If you havn't looked at Dents [dents.org] yet, you should. It's a nifty modular DNS server. And, AFAIK, there is no "non free" code.
  • Just read the article, and to preempt the usual misinformed-just-enough-to-flame crowd: BIND is still open source - it's a particular add-on, the DNSafe that does not meet the OSD definition. Another reader was quick to point out that this is being worked on as well.

    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...
  • Not to disagree with Bruce, but "technically superior" hasn't been proved yet for DENTS. However, I do think the more modular architecture will make DENTS easier to extend and improve in the long run. And a few of its ideas (algorithmic name assignments) are very important for large-scale hosting and reverse-lookups.

    Also, in recent discussion on debian-devel, one guy from ISC said that even he was disturbed that BIND is the only production DNS implementation out there (because any BIND security problem becomes a problem everywhere on the 'net). That alone should be a good reason to get DENTS out the door. (Modern internet standards have to have multiple interoperable implementations, to avoid this very problem.)
  • 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 [debian.org].
  • 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.
  • I do have to wonder (and probably and going to be flamed to no end on this)
    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....

    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/co nfig/trusted-keys.phtml [isc.org] to learn more about DNSSEC and how it works.
  • Additionally, I'd like to point out that DNSSEC does not depend on RSA; other signature systems (DH and DSA) are possible too.

    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...

  • No-one outside the BIND group wants the awful RSAREF code.

    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.

  • MS Win2000 implementing some half-arsed version of the Dynamic DNS RFC

    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.

  • Specs can be changed.

    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...

  • Re:Clearing up some misconceptions (Score:3)

    by bjk4 ( 885 ) on Saturday September 11, 1999 @04:44AM (#1689598) Homepage
    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)

  • Why couldn't they use ElGammal? (Score:3)

    by Svartalf ( 2997 ) on Saturday September 11, 1999 @04:07AM (#1689599) Homepage
    After all, the patents expired on it and GPG uses it right now (besides, I've heard that it's better than RSA anyhow...)

  • there was PGP, now there is GnuPG (Score:3)

    by jelle ( 14827 ) on Saturday September 11, 1999 @03:34AM (#1689600) Homepage
    So does this mean somebody should stand up and challenge the standard, and maybe make something based on The GNU Privacy Guard (GPG) [gnupg.org] to get encryption into something called GBIND?

    Is the Open Source community strong enough yet to overturn a bad standard in such way?

  • Re:Being worked out. (Score:3)

    by Joheines ( 34255 ) on Saturday September 11, 1999 @03:32AM (#1689601)
    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?

  • Re:So what if you can't split the code? (Score:3)

    by tialaramex ( 61643 ) on Saturday September 11, 1999 @05:17AM (#1689602) Homepage
    No! It's always a bad idea to allow a small erosion of values in exchange for some apparently wonderful benefit. The problem is that erosion adds up, and it's much harder to fight for it once it's gone. If Debian permits a non-open package to go into Debian core (where BIND belongs) then it's just one small step before you're signing your soul over just to get a usable version of Linux.

    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.

  • Clearing up some misconceptions (Score:3)

    by bwelling ( 62243 ) on Saturday September 11, 1999 @03:48AM (#1689603) Homepage
    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.

  • Re:So what if you can't split the code? (Score:3)

    by techt ( 87303 ) on Saturday September 11, 1999 @05:12AM (#1689604)
    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.

  • Non-DFSG == non-open-source, pretty much. (Score:4)

    by Paul Crowley ( 837 ) on Saturday September 11, 1999 @03:55AM (#1689605) Homepage Journal
    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.
    --

  • So what if you can't split the code? (Score:4)

    by Decibel ( 5099 ) on Saturday September 11, 1999 @04:48AM (#1689606) Journal
    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.

    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 :-) and following the issues.

    the AC

  • Being worked out. (Score:5)

    by Razron ( 12415 ) on Saturday September 11, 1999 @03:27AM (#1689608) Homepage
    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.

  • Re:Diffie Hellman (Score:5)

    by disappear ( 21915 ) on Saturday September 11, 1999 @04:24AM (#1689609) Homepage
    > 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!)

Slashdot Top Deals

"Look! There! Evil!.. pure and simple, total evil from the Eighth Dimension!" -- Buckaroo Banzai

Close