Clarifications on the recent BIND stuff
Hi,
Apologies for the length of this note, but I felt an omnibus response
would be the least intrusive (I imagine this issue is pretty far down on
your priority list). I was just perusing your archives and thought I'd
clarify a couple of things:
------
From: Bdale Garbee <bdale@gag.com>
Date: Mon, 6 Sep 1999 12:24:08 -0600
>> 3. Somehow separate the DNSSEC code from new BIND releases. I
>> suspect this will be very hard.
> My analysis, and that of a couple of other folks, is that this is
> hard for 8.2.1, getting harder for 8.2.2, and likely to be nearly
> impossible for 9.X.
Actually, it should be fairly easy, both in v8.2.* and in v9. There is
a library interface (DST) between BIND and the crypto code. Removing
RSA (or DSA) primarily requires mucking about with a makefile or two and
deleting some files. However, we'll be doing this for you all so it
isn't really an issue.
> it appears there's nothing in the security spec that requires
> the RSA code, it was just convenient,
What really happened was the original DNSSEC spec _only_ supported RSA.
Paul Vixie and others made a stink about this and the author of DNSSEC
(Donald Eastlake) added the ability to use other algorithms (albeit in a
sub-optimal way (IMHO)). BIND 8.2.* has two algorithms for DNSSEC, RSA
and DSA. However, for performance reasons, RSA is the "recommmended"
algorithm. Both implementations are, shall we say, sub-optimal.
Unfortunately, DSA is more sub-optimal. In tests, we found that DSA was
60 times slower than RSA. For small zones, this won't be an issue. For
large zones (like .COM), DSA is simply infeasible.
The problem is that the DNSSEC specification is (IMHO) braindead. If a
server wishes to support both DSA and RSA (and any other algorithms), it
means the records on the server must be signed by _both_ algorithms and
the response must carry _both_ signatures. There are other fundamental
flaws (e.g., the whole key exchange issue is not addressed), however
strengthening the DNS infrastructure was felt to be significant enough
to warrant the deployment of the protocol.
What this means to you all is that, given RSA is so much faster than
DSA, most "early adopters" will be signing their zones with RSA and will
almost certainly not bother with DSA. As a result, since you will not
be using RSA, you will be unable to use DNSSEC with sites that use RSA.
This isn't a big issue for the near term -- the implementation of DNSSEC
in BIND 8.2.* is minimalistic and intended only to give people a
glimmering of the pain they will need to endure to have a strong
infrastructure. However, BIND version 9 (due out in public beta in
January) will contain a full implementation of DNSSEC. If the protocol
isn't fixed by then, things may get a bit more serious.
> and it is that code for
> which an export license has been acquired or some such. Thus,
> changing that code is likely to cause non-us issues in addition
> to the non-free issues.
No. Since DNSSEC only uses authentication, it is exempt from the BXA
regulations on export of strong cryptography. Or at least, that's what
our two lawyers told us. BXA has been known to go a bit off the books
at times...
------
From: Todd Graham Lewis <tlewis@mindspring.net>
Date: Thu, 9 Sep 1999 10:17:53 -0400 (EDT)
> However, this episode does reinforce the dangers of relying
> exclusively on bind.
There are dangers in any mono-cultural ecology. I (honestly) look
forward to the day I don't have to worry about the entire Internet
infrastructure being put at risk because of a security hole or bug in
BIND...
> Vixie has publically contemplated taking
> bind development commercial, and there's nothing in the license
> stopping him from doing so.
FUD.
First, Paul is merely the release engineer for BINDv8 and has no ongoing
role in future BIND developments (e.g., he is not taking part in the
development of BINDv9) due to other commitments. He also cannot dictate
the direction of BIND as he is not ISC, he is only one of five board
members (the others being myself, Evi Nemeth, Steve Wolff, and Teus
Hagen).
Also, while it is true that there is nothing in ISC's license (being a
BSD derivative) that prohibits the development of BIND being turned
commercial, ISC is a California non-profit corporation which means that
_any_ action by the ISC board that can be deemed against the public
interest can be brought up with the California state attorneys general.
As opposed to other states, the California AGs actually take that sort
of thing seriously and should they determine the public interest was
violated, the ISC _board members_ can be held liable. Typical
punishments in such cases are rather large fines, which the board
members would be required to pay. As these fines in the past have
amounted to several millions of dollars, I personally wouldn't be
interested in risking it.
And besides, any attempt to turn BIND commercial will simply result in a
fork.
------
From: Philip Hands <phil@hands.com>
Date: 10 Sep 1999 08:39:17 +0100
> With the introduction of DNSSEC (secure DNS) it needs
> encryption,
As mentioned, it needs authentication, not encryption. This is
significant as it means we are exempt from export restrictions
(according to our lawyers).
> and is using RSA, which makes the latest BIND patent
> encumbered in the US.
Yes, until Oct, 2000 (not that I'm counting the days... :-)).
> It is rumoured that future versions may
> be covered by a license that is less free than BSD.
These rumors are false. The ISC board has explicitly required all
versions of BINDv8 and BINDv9 to come under the same BSD-derived license
that it currently has.
------
From: Richard Stallman <rms@gnu.org>
Date: Sat, 11 Sep 1999 03:26:54 -0400
> Even if the BIND developers intend to cooperate fully with the
> free software community, we still have the problem of how to
> support DNSSEC, preferably without RSA.
This will, I believe, require modification to the DNSSEC protocol
(something I feel is necessary regardless of what one thinks of the use
of RSA). ISC plans on proposing protocol modifications at the spring
IETF.
------
From: "J.H.M. Dassen \(Ray\)" <jdassen@wi.LeidenUniv.nl>
Date: Sat, 11 Sep 1999 19:01:25 +0200
> I seem to recall that the IETF in general does not accept into
> RFC status proposals that depend on patent-encumbered algorithms.
I believe the IETF policy is that patented algorithms are acceptable in
standards if those patents are made available under "reasonable and
non-exclusionary" licensing terms. The DNSsafe license, which permits
the use of RSA for DNSSEC only for no licensing fee regardless of use,
was I believe considered "reasonable". John Gilmore did most of the
negotiations and I believe he thought it was a reasonable compromise.
------
I hope this makes things clearer. If there are any questions regarding
ISC's licensing, BINDv8 (or v9), or anything related to ISC, feel free
to contact me directly.
Regards,
-drc
Executive Director, ISC
Reply to: