From owner-dns-security Thu Jul 24 01:32:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA19234 for dns-security-outgoing; Thu, 24 Jul 1997 01:28:15 -0400 (EDT) Date: Thu, 24 Jul 1997 01:30:58 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: draft-ietf-dnssec-secext2-00.txt Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk Hi, I have submitted a revised basic dnssec draft to internet-drafts. There is no change in the fundamental strucutre of DNS security but a number of details have been changed based on implementation experience and requests from potential users. The draft is large enough that I didn't want to just mail it out so to make it more rapdily available, I have put it up for anonymous ftp at . The document is not as polished as I would like but I wanted to get it out so there would be a chance for comments and one more round of editing before the Munich I-D cutoff date. The most serious change is the addition of two fields to the KEY RR which may require getting a new RR type number, deprecating the RFC 2065 KEY RR, and eventually reclaiming the old number. Thanks, Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-dns-security Fri Jul 25 04:41:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA29640 for dns-security-outgoing; Fri, 25 Jul 1997 04:39:33 -0400 (EDT) Date: Fri, 25 Jul 1997 11:44:10 +0300 (EET DST) Message-Id: <199707250844.LAA00722@guava.araneus.fi> To: "Donald E. Eastlake 3rd" , charlie_kaufman@iris.com CC: dns-security@tis.com Subject: Re: draft-ietf-dnssec-secext2-00.txt In-Reply-To: References: From: gson@araneus.fi (Andreas Gustafsson) Sender: owner-dns-security@ex.tis.com Precedence: bulk "Donald E. Eastlake 3rd" writes: > I have submitted a revised basic dnssec draft to internet-drafts. There is > no change in the fundamental strucutre of DNS security but a number of > details have been changed based on implementation experience and requests > from potential users. > [...] > The most serious change is the addition of two fields to the KEY RR which may > require getting a new RR type number, deprecating the RFC 2065 KEY RR, and > eventually reclaiming the old number. As an implementer, I have the following comments regarding RFC2065. The new draft neither causes nor cures these problems, but since it introduces incompatible changes to the KEY RR format, this may be a good opportunity (or perhaps even the last chance) to introduce incompatible changes to the SIG and NXT records, too. 1. The SIG "labels" field RFC2065 section 4.5 states: The "labels" field does not appear in the file representation as it can be calculated from the owner name. This introduces an unfortunate irregularity into the process of parsing the textual representation of RRs. When parsing an RR of any type other than SIG, the owner name and the RR data can be parsed separately, and the routine that parses the data does not need the owner name as an input parameter. This is not the case for the SIG RR, which can only be fully constructed from its textual representation if the owner name is known. Although this is not a problem in BIND due to the implementation of its RR parser as a giant C "switch" statement, it is a problem in a more structured or object-oriented name server implementation. If each RR is parsed by a separate subroutine and these subroutines are to have a common interface, supporting the SIG format requires passing the owner name an additional parameter to every such subroutine, even though all of them except for the SIG-parsing routine will ignore it. To avoid this irregularity, it would be better to include an explicit "labels" field in the textual representation. As a matter of fact, the syntax example in RFC2065 section 5.3 already does this, in contradiction with the actual specification in section 4.5 :-) Alternatively, the complete original owner name could be included in the RR data (and in the text representation) instead of the current numeric "labels" field. If domain name compression is used, the name will typically compress into a two-byte sequence, only one byte more than the numeric "labels" field. Stating the original owner name explicitly in the master file format would also (IMHO) be vastly more readable than the current practice of making it merely implied by context. 2. The NXT bit map The NXT RR currently uses a bit map of RR type numbers to represent a set of RR types. Since RR type numbers are 16-bit unsigned integers, this bit map may potentially become very large - up to 8192 bytes, an impractically large size for inclusion in a DNS message. In effect, the widespread use of NXT records in their current form would render almost all of the available RR type number space useless. The historical use of a similar bit map to encode port numbers in the WKS record has long been considered a bad idea, e.g. due to its inability to represent TCP port 6000 as used for the X window system. As an alternative to the bit map representation, the RR types could be represented as a list of (unique) 16-bit RR type numbers. This encoding may use slightly more space than a bit map when only low-numbered RRs are present, but uses dramatically less space than a bit map when high-numbered RRs are involved. -- Andreas Gustafsson, gson@araneus.fi From owner-dns-security Fri Jul 25 10:20:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01732 for dns-security-outgoing; Fri, 25 Jul 1997 10:19:39 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: dns-security@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-secext2-00.txt Date: Fri, 25 Jul 1997 09:45:01 -0400 Message-ID: <9707250945.aa08842@ietf.org> Sender: owner-dns-security@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Domain Name System Security Extensions Author(s) : D. Eastlake Filename : draft-ietf-dnssec-secext2-00.txt Pages : 47 Date : 07/24/1997 Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers in many cases. The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions and requests. This document incorporates feedback from implementors and potential users to the existing Proposed Standard in RFC 2065. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-secext2-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext2-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-secext2-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970724121150.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-secext2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-secext2-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970724121150.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security Sat Jul 26 17:55:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10541 for dns-security-outgoing; Sat, 26 Jul 1997 17:49:59 -0400 (EDT) Message-Id: <3.0.1.32.19970726170833.006e115c@pop.hq.tis.com> X-Sender: ogud@pop.hq.tis.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 26 Jul 1997 17:08:33 -0400 To: dns-security@tis.com From: Olafur Gudmundsson Subject: Changes in DNSSEC specification, Request For Discussion Cc: dee@cybercash.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dns-security@ex.tis.com Precedence: bulk In light of implementation experience and the changes in requirements over time, some changes to the format of the KEY (type=25) resource record RDATA section is being proposed. This proposal is documented fully in the new draft submitted by Donald Eastlake. This message summarizes and presents the motivation for the changes. KEY record New Format Old Format change Field Name Length Field Name Length ====== ======================== ======================== *lengthened* flags 4 bytes flags 2 bytes *new* preference 2 bytes *new* key indent 2 bytes protocol 1 byte protocol 1 byte algorithm 1 byte algorithm 1 byte public key 0-? bytes public key 0-? bytes The flags field is doubled in size. The number of bits in the current flags field has been nearly exhausted, and DNSSEC has not yet been deployed (widely). The 16 new bits are added to the end of the field (bits 16-31 of the field). In addition to the change in size, bit 10 has been assigned to the TLS security standard. One bit specified in RFC2065 (bit 2 Experimental) has been retired. The preference field is used to indicate the wishes of a key owner when a choice is made by another entity between equally qualified keys. For example, user 1 is going to encrypt an email message with a public key of user 2 to secretly send a message to that user. User 2 may have 3 public keys with the e-mail bit on, each of different strengths (key lengths). User 2 can guide user 1's choice by indicating the most preferred with the lowest value of the three in the preference field. The key identifier field contains an identifier used to refer to a particular key under the owner name. The value in this field replaces the key footprint, calculated in a key algorithm dependent manner in RFC 2065. In testing, it was found that this footprint offered no advantages to a user (application) set tag for the keys. While neither a key identifier nor key footprint do not guarantee complete uniqueness, with identifiers, a user has control over handling conflicting identifiers. (In the SIG RR, type 24, the footprint is now called the key identifier. This is not a change in the protocol format, just the nomenclature.) There are number of minor changes none of which should cause any problems. The main problem is, the KEY record Do we think the current KEY format is good enough and we should rather play games with the specification of it than change it. For example KEY has 3 bits to indicate type of key. The bits are mutually exclusive, we can compress this to two bits, and so on. If we change the KEY record type number do we have to change the type name to KY or something like that. The deployed base of software that is aware of KEY records is significant. What I would like is for the community to speak up what they think about the changes in the specification Olafur Gudmundsson From owner-dns-security Sat Jul 26 17:55:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10542 for dns-security-outgoing; Sat, 26 Jul 1997 17:50:00 -0400 (EDT) Message-Id: <3.0.1.32.19970726172339.006ebcf0@pop.hq.tis.com> X-Sender: ogud@pop.hq.tis.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 26 Jul 1997 17:23:39 -0400 To: gson@araneus.fi (Andreas Gustafsson) From: Olafur Gudmundsson Subject: Re: draft-ietf-dnssec-secext2-00.txt Cc: "Donald E. Eastlake 3rd" , dns-security@tis.com In-Reply-To: <199707250844.LAA00722@guava.araneus.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dns-security@ex.tis.com Precedence: bulk At 11:44 AM 7/25/97 +0300, Andreas Gustafsson wrote: >"Donald E. Eastlake 3rd" writes: > >As an implementer, I have the following comments regarding RFC2065. >The new draft neither causes nor cures these problems, but since it >introduces incompatible changes to the KEY RR format, this may be a >good opportunity (or perhaps even the last chance) to introduce >incompatible changes to the SIG and NXT records, too. Yes this is the last chance for a long time, and maybe it is to late. > > >1. The SIG "labels" field > >RFC2065 section 4.5 states: > > The "labels" field does not appear in the file representation as it > can be calculated from the owner name. > >This introduces an unfortunate irregularity into the process of >parsing the textual representation of RRs. When parsing an RR of any >type other than SIG, the owner name and the RR data can be parsed >separately, and the routine that parses the data does not need the >owner name as an input parameter. This is not the case for the SIG >RR, which can only be fully constructed from its textual >representation if the owner name is known. This is changed in the new draft, now all fields are supposed to be represented in the presentation format. I hated this specification and it did not save us any work in implementation. > >2. The NXT bit map > >The NXT RR currently uses a bit map of RR type numbers to represent a >set of RR types. Since RR type numbers are 16-bit unsigned integers, >this bit map may potentially become very large - up to 8192 bytes, >an impractically large size for inclusion in a DNS message. New types are introduced slowly (0-7 a year). It will take a long time to fill the type space. > >In effect, the widespread use of NXT records in their current form >would render almost all of the available RR type number space useless. Type numbers are assigned by a central authority, in sequential order. Currently the highest type is about 40 (5 bytes in NXT). The types defined in the 25x range are meta types and are not stored and will thus never be reflected in NXT bitmap. > >The historical use of a similar bit map to encode port numbers in the >WKS record has long been considered a bad idea, e.g. due to its >inability to represent TCP port 6000 as used for the X window system. This port number was a bad choice and port numbers in UNIX reserve the first 1024 ports for privileged processes. I do not think UNIX port numbering should be used as a guiding light here. > >As an alternative to the bit map representation, the RR types could be >represented as a list of (unique) 16-bit RR type numbers. This >encoding may use slightly more space than a bit map when only >low-numbered RRs are present, but uses dramatically less space than a >bit map when high-numbered RRs are involved. Interesting idea, this was discussed by Donald and myself when I started pushing for replacement of the NXD record with the NXT record. The consensus then was that each name would have 3 records minimum stored, SIG and NXT and some non security record. This requires 6 bytes in your schema. We expected representing the types explicitly would take more space. Second consideration was that space now is more expensive than space later when we have faster and cheaper hardware, networks etc. >-- >Andreas Gustafsson, gson@araneus.fi Olafur From owner-dns-security Sat Jul 26 19:17:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA10881 for dns-security-outgoing; Sat, 26 Jul 1997 19:14:26 -0400 (EDT) Message-Id: Date: Sat, 26 Jul 97 16:22 PDT From: randy@psg.com (Randy Bush) To: Olafur Gudmundsson Cc: dns-security@tis.com Subject: Re: draft-ietf-dnssec-secext2-00.txt References: <199707250844.LAA00722@guava.araneus.fi> <3.0.1.32.19970726172339.006ebcf0@pop.hq.tis.com> Sender: owner-dns-security@ex.tis.com Precedence: bulk >> 2. The NXT bit map >> >> The NXT RR currently uses a bit map of RR type numbers to represent a >> set of RR types. Since RR type numbers are 16-bit unsigned integers, >> this bit map may potentially become very large - up to 8192 bytes, >> an impractically large size for inclusion in a DNS message. > New types are introduced slowly (0-7 a year). It will take a long time to > fill the type space. And previously new types become obsolete at about the same rate as the introduction of new new types :-)/2. Thus, we should either recycle the numbers, or the NXT RR might use an encoding which does not use space proportional to the maximum RR number. randy From owner-dns-security Sun Jul 27 11:22:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14457 for dns-security-outgoing; Sun, 27 Jul 1997 11:20:28 -0400 (EDT) Date: Sun, 27 Jul 1997 18:28:08 +0300 (EET DST) Message-Id: <199707271528.SAA01024@guava.araneus.fi> To: randy@psg.com (Randy Bush) Cc: Olafur Gudmundsson , dns-security@tis.com Subject: Re: draft-ietf-dnssec-secext2-00.txt In-Reply-To: References: <199707250844.LAA00722@guava.araneus.fi> <3.0.1.32.19970726172339.006ebcf0@pop.hq.tis.com> From: gson@araneus.fi (Andreas Gustafsson) Sender: owner-dns-security@ex.tis.com Precedence: bulk randy@psg.com (Randy Bush) said: > And previously new types become obsolete at about the same rate as the > introduction of new new types :-)/2. Thus, we should either recycle the > numbers, or the NXT RR might use an encoding which does not use space > proportional to the maximum RR number. Recycling RR numbers is not trivial. In particular, the new RRs risk being corrupted by any old secondary and caching name servers that still support the old RR type. Such servers are not likely to go away soon. One mechanism for corruption is that an old server will attempt to uncompress what it believes are compressed domain names in the RR, even if those bytes are actually used for non-name data in the new RR. Another is that some servers (e.g., BIND) internally convert the RR data into a text format which cannot be reliably converted back into binary data for all possible values of the binary data. It might be possible to work around these problems by recycling RR numbers only for use by new RRs whose structure is "sufficiently similar" to that of the recycled old RR, but I still think it's a bad idea. -- Andreas Gustafsson, gson@araneus.fi From owner-dns-security Sun Jul 27 11:34:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14528 for dns-security-outgoing; Sun, 27 Jul 1997 11:32:24 -0400 (EDT) Message-Id: Date: Sun, 27 Jul 97 08:40 PDT From: randy@psg.com (Randy Bush) To: gson@araneus.fi (Andreas Gustafsson) Cc: Olafur Gudmundsson , dns-security@tis.com Subject: Re: draft-ietf-dnssec-secext2-00.txt References: <199707250844.LAA00722@guava.araneus.fi> <3.0.1.32.19970726172339.006ebcf0@pop.hq.tis.com> <199707271528.SAA01024@guava.araneus.fi> Sender: owner-dns-security@ex.tis.com Precedence: bulk >> And previously new types become obsolete at about the same rate as the >> introduction of new new types :-)/2. Thus, we should either recycle the >> numbers, or the NXT RR might use an encoding which does not use space >> proportional to the maximum RR number. > Recycling RR numbers is not trivial. Understand. I was being unusually subtle. I was endorsing your suggestion that the NXT RR use an encoding which was kinder to high numbered RR types. randy From owner-dns-security Sun Jul 27 17:58:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA15998 for dns-security-outgoing; Sun, 27 Jul 1997 17:55:54 -0400 (EDT) To: dns-security@tis.com Subject: Re: draft-ietf-dnssec-secext2-00.txt In-Reply-To: Your message of "Sat, 26 Jul 1997 17:23:39 -0400." <3.0.1.32.19970726172339.006ebcf0@pop.hq.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Jul 1997 08:03:41 +1000 Message-Id: <7377.870041021@munnari.OZ.AU> From: Robert Elz Sender: owner-dns-security@ex.tis.com Precedence: bulk Date: Sat, 26 Jul 1997 17:23:39 -0400 From: Olafur Gudmundsson Message-ID: <3.0.1.32.19970726172339.006ebcf0@pop.hq.tis.com> | >2. The NXT bit map | > | >The NXT RR currently uses a bit map of RR type numbers to represent a | >set of RR types. Since RR type numbers are 16-bit unsigned integers, | >this bit map may potentially become very large - up to 8192 bytes, | >As an alternative to the bit map representation, the RR types could be | >represented as a list of (unique) 16-bit RR type numbers. If a change were to be desired, you want a combination of those two, not one or the other - a simple list of 16 bit numbers could easily become absurdly large, and in practice, probably quicker than a bit vector. If something else is wanted, perhaps a list of 32 bit structures, in which the first byte is an offset multiple, and the other 24 bits are a bit vector. It is kind of hard to describe in words how this works, so ... l = ; /* an int */ p = ; /* a char * or unsigned char */ off = 0; /* an int */ while (l >= 4) { off += *(unsigned char *)p; p++; for (i = 0; i < 3; i++) { for (j = 0; j < 7; j++) { if (*p & (1 << j)) printf("value %d found\n", off * 24 + i * 8 + j; } p++; } off += 3; l -= 4; } The code is crude, and, of course not tested, so could have bugs, but I think it describes what I mean better than I can in words. This way to represent all of the current 40 RR types would take 8 bytes, an increase over the current 5, but not nearly as bad as the potential 80 it would need with a list of 16 bit values (8 bytes there would be just allow 4 RR types, which while about right, is probably not quite enough). This encoding also permits a gap of up to 6120 types to be skipped without wasting anything at all (other than the 32 bits used to encode the 24 bits that surround the value wanted), and gaps bigged than that just need one 32 bit value for each 6120 RR numbers skipped - 40 bytes (10 * 4) would allow RR 65535 to be represented (if no others are, or if the others that are happen to fall in the words that need to be there). I'm not sure that this kind of complexity is needed, but I am fairly sure that a list of RR types as individual numbers isn't the way to go. kre From owner-dns-security Mon Jul 28 16:15:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24313 for dns-security-outgoing; Mon, 28 Jul 1997 16:01:27 -0400 (EDT) Message-Id: <199707282009.NAA04954@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Olafur Gudmundsson cc: dns-security@tis.com, dee@cybercash.com, gnu@toad.com Subject: Re: Changes in DNSSEC specification, Request For Discussion In-reply-to: <3.0.1.32.19970726170833.006e115c@pop.hq.tis.com> Date: Mon, 28 Jul 1997 13:09:54 -0700 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk > What I would like is for the community to speak up what they think > about the changes in the specification My initial take is that the new KEY records are not a sufficient improvement over the existing KEY records that it's worth making an incompatible change. I agree that there are things in RFC 2065 that we can and should tighten up, but let's NOT make any changes that render deployed code incompatible. DNSSEC is not a draft any more, it's a Proposed Standard. We can't keep dinking around with it to our hearts' content. There are things we would now like to change in IP and TCP and SMTP and SNMP and PPP and lots of other protocols, but we live with them and the world is much better off as a result. *Please* don't set back the process of standardizing and deploying DNSSEC, in return for some relatively useless changes. The benefit of DNSSEC will be great -- but the benefit is still zero until people can use it. Every day we slow down its deployment we reduce that benefit. The proposed spec changes don't add enough benefit to offset the reduction. In case you forgot, governments worldwide are actively trying to *outlaw* DNS security. (The outgoing UK Conservative government was the most obvious -- their draft law at http://www.dti.gov.uk/pubs/ would outlaw the provision of digital signatures for other parties, whether for free or not. DNSSEC depends on parent zones being able to sign child zones' keys. Luckily the Labour party won the election, and the proposal has stalled, but since NSA is pushing it in dozens of countries, it will be back.) I suggest that we get DNSSEC working and deployed before these "proposals" are actually being debated in legislatures. It would help to kill the bills to be able to say "five thousand companies in this country are already doing this every day without a problem -- now why do you want to make it illegal?" The three incompatible changes to the KEY record are: > *lengthened* flags 4 bytes flags 2 bytes The RFC 2065 flags field has four reserved bits. But it also has many bits allocated that we could simply recycle in a backward-compatible way. Here are the flags from RFC 2065 (excerpted): Bit 0 and 1 are the key "type" field. Bit 0 a one indicates that use of the key is prohibited for authentication. Bit 1 a one indicates that use of the key is prohibited for confidentiality. Bit 2 is the "experimental" bit. Bits 3-4 are reserved and must be zero. Bit 5 on indicates that this is a key associated with a "user" or "account" at an end entity, usually a host. Bit 6 on indicates that this is a key associated with the non- zone "entity" whose name is the RR owner name. This will commonly be a host ... Bit 7 is the "zone" bit and indicates that this is a zone key for the zone whose name is the KEY RR owner name. This is the public key used for DNS data origin authentication. Bit 8 is reserved to be the IPSEC [RFC 1825] bit ... Bit 9 is reserved to be the "email" bit ... Bits 10-11 are reserved and must be zero. Bits 12-15 are the "signatory" field. If non-zero, they indicate that the key can validly sign RRs or updates of the same name. But protocols are only supposed to get a flags bit if the exact same keying material (KEY RR) can be used unchanged by several protocols. RFC 2065 says: It is intended that new uses of DNS stored keys would initially be implemented, and operational experience gained, using the experimental range of the protocol octet. If demand for widespread deployment for the indefinite future warrants, a value in the assigned range would then be designated for the protocol. Finally, (1) should the protocol become so widespread in conjunction with other protocols and with which it shares key values that duplicate RRs are a serious burden and (2) should the protocol provide substantial facilities not available in any protocol for which a flags field bit has been allocated, then one of the remaining flag field bits may be allocated to the protocol. Since neither DNS zones, IPSEC, nor Email qualifies for (1), none of them should (at this time) get a dedicated flag bit. They are just protocols, which will each have unique keys. Since no protocol numbers are allocated, in either RFC 2065 or in the proposed draft, perhaps this is why people keep inappropriately assigning flag bits for protocols! I suggest that we assign: 1 DNS Zone signing 2 IP Security 3 Email 4 TLS 5 MUSE (email encryption by mail transfer agents) and make it *trivial* for other groups that want to use key records to get an assignment. (I think we should dump the idea that people who want to deploy KEY records *must* do it in the experimental range first; we've just allocated under 2% of the available values.) Making these allocations, and making it easy to get a protocol number for new uses, will eliminate the bit pressure on the flags field. If we reserved these three bits, and the Experimental bit (as Don's draft proposed), then we would go from four spare bits to eight (out of 16). I think that's enough for the long haul, and would not require us to double the size of the field. > *new* preference 2 bytes This new field, which would express MX-like preference among several keys supplied for the same protocol, would probably be useful. But I don't think it's worth making an incompatible change for it at this point. > *new* key ident 2 bytes This field is unnecessary. In discussions with Olafur, it appears that the idea is to add a new requirement that zone owners who create KEY records *must* use unique 16-bit key identifiers (must prevent duplication). This isn't explicit in Don's draft, though. What they were trying to do was to make sure that implementations would never encounter a case where two key ID's ("key fingerprints" in SIG records in RFC 2065) are the same unless the keys are identical. But coding the implementations so it will examine a short list of keys, if they happen to have the same fingerprint, is a much better approach. Requiring that key-issuing sites serialize on a single key-numbering location, in order to provide a slight programming convenience, adds a system-level complication in order to solve a local problem. And an unenforceable and uncheckable requirement of uniqueness, that is depended on for security, creates a security problem where no hole used to exist. It's also alleged that the previous method of computing a "key fingerprint" in SIG records doesn't work well with non-RSA keys. I haven't seen evidence of that, though. Realize that we're populating a 16-bit hash space with sets of keys from the same domain name (signer name). Even if a single domain name had a thousand keys (which would be rather tough to retrieve in response to a single DNS query) it would still only fill about 2% of the 65,536 possible hashes; the chance of collisions is low. Even if one occurs, you just get a minor performance problem *for that domain name*. In summary, we should deploy the formats that we have now, and strongly resist the temptation to dink with them. We must provide the benefit of Secure DNS to the world soon (both to prevent the kind of spoofing that is going on every day -- try http://www.per if you don't believe me and to allow keys to be published for other protocols) or we will not be able to provide it at all. John Gilmore From owner-dns-security Tue Jul 29 03:25:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA27636 for dns-security-outgoing; Tue, 29 Jul 1997 03:22:59 -0400 (EDT) Date: Tue, 29 Jul 1997 10:31:18 +0300 (EET DST) Message-Id: <199707290731.KAA00455@guava.araneus.fi> To: Olafur Gudmundsson Cc: "Donald E. Eastlake 3rd" , dns-security@tis.com Subject: Re: draft-ietf-dnssec-secext2-00.txt In-Reply-To: <3.0.1.32.19970726172339.006ebcf0@pop.hq.tis.com> References: <199707250844.LAA00722@guava.araneus.fi> <3.0.1.32.19970726172339.006ebcf0@pop.hq.tis.com> From: gson@araneus.fi (Andreas Gustafsson) Sender: owner-dns-security@ex.tis.com Precedence: bulk > >In effect, the widespread use of NXT records in their current form > >would render almost all of the available RR type number space useless. > Type numbers are assigned by a central authority, in sequential order. > Currently the highest type is about 40 (5 bytes in NXT). They may be assigned sequentially now, but they need not necessarily be assigned sequentially in the future. For example, it has been suggested that a range of RR type numbers could be reserved for future RRs using a self-encoding format that allows name servers to determine the location of any compressed domain names in the RR. This would allow name servers to treat new types of RRs (within this range) transparently. Certainly there may also be other, yet unforeseen applications for non-sequentially allocated numbers, or for large sequential groups of interrelated RRs. If you are really saying that RR type numbers over some limit should never be assigned, are you not in effect attempting to override the IANA's authority to assign those numbers? Shouldn't you instead ask the IANA to make all the numbers above this limit "reserved (NXT inefficient)", similar to the way some PPP protocol numbers are "reserved (transparency inefficient)"? If the IANA actually were to get a request to reserve some 99% of the assignable number space in one fell swoop, I would expect them to have the sense to refuse it. -- Andreas Gustafsson, gson@araneus.fi From owner-dns-security Tue Jul 29 04:26:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA27902 for dns-security-outgoing; Tue, 29 Jul 1997 04:25:33 -0400 (EDT) Date: Tue, 29 Jul 1997 11:31:53 +0300 (EET DST) Message-Id: <199707290831.LAA00507@guava.araneus.fi> To: Robert Elz Cc: dns-security@tis.com Subject: Re: draft-ietf-dnssec-secext2-00.txt In-Reply-To: <7377.870041021@munnari.OZ.AU> References: <3.0.1.32.19970726172339.006ebcf0@pop.hq.tis.com> <7377.870041021@munnari.OZ.AU> From: gson@araneus.fi (Andreas Gustafsson) Sender: owner-dns-security@ex.tis.com Precedence: bulk > | >As an alternative to the bit map representation, the RR types could be > | >represented as a list of (unique) 16-bit RR type numbers. > > If a change were to be desired, you want a combination of those two, not > one or the other - a simple list of 16 bit numbers could easily become > absurdly large, and in practice, probably quicker than a bit vector. In practice, I don't see any names with dozens of different RR types out there in the DNS today. Even in the worst-case scenario of single name with all 40 of the currently allocated RR types, the corresponding NXT type list would use 80 bytes, no more absurd than a typical KEY record. I do agree, though, that there is a potential problem if some future application of the DNS were to use a large number of distinct RR types. > If something else is wanted, perhaps a list of 32 bit structures, in which > the first byte is an offset multiple, and the other 24 bits are a bit > vector. > > [C code omitted] This would certainly be acceptable. -- Andreas Gustafsson, gson@araneus.fi From owner-dns-security Tue Jul 29 06:52:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA28721 for dns-security-outgoing; Tue, 29 Jul 1997 06:51:56 -0400 (EDT) Message-Id: <3.0.32.19970728161729.0073818c@cic-mail.lanl.gov> X-Sender: u114212@cic-mail.lanl.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 28 Jul 1997 16:20:15 -0600 To: dns-security@tis.com From: "Ron Daniel, Jr." Subject: Re: Changes in DNSSEC specification, Request For Discussion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dns-security@ex.tis.com Precedence: bulk At 01:09 PM 7/28/97 -0700, John Gilmore wrote: [Lots of good stuff deleted] >In summary, we should deploy the formats that we have now, and >strongly resist the temptation to dink with them. Amen. In our (admittedly very limited) experience with DNSSEC, we have not had problems that are addressed by the proposed changes. Backward incompatible changes, with their consequent delays (potentially even requiring the export issue to be revisited) are a much more serious problem right now. IMHO, unless show-stopping security holes are found, the RR formats are now carved in stone. Lets get some experience with what we have. Then, when problems are found, a new WG can be chartered to do DNSSEC-NG. Regards, Ron Daniel Jr. voice:+1 505 665 0597 Advanced Computing Lab fax:+1 505 665 4939 MS B287 email:rdaniel@lanl.gov Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel Los Alamos, NM, USA, 87545 From owner-dns-security Tue Jul 29 10:30:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01130 for dns-security-outgoing; Tue, 29 Jul 1997 10:29:32 -0400 (EDT) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: <199707290731.KAA00455@guava.araneus.fi> References: <3.0.1.32.19970726172339.006ebcf0@pop.hq.tis.com> <199707250844.LAA00722@guava.araneus.fi> <3.0.1.32.19970726172339.006ebcf0@pop.hq.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Jul 1997 10:33:36 -0400 To: gson@araneus.fi (Andreas Gustafsson) From: Edward Lewis Subject: Re: draft-ietf-dnssec-secext2-00.txt Cc: Olafur Gudmundsson , "Donald E. Eastlake 3rd" , dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk Tangentially, (the some comments supporting John Gilmore's message)... At 3:31 AM -0400 7/29/97, Andreas Gustafsson wrote: >For example, it has been suggested that a range of RR type numbers >could be reserved for future RRs using a self-encoding format that >allows name servers to determine the location of any compressed domain >names in the RR. This would allow name servers to treat new types of >RRs (within this range) transparently. It's funny you should mention this. The location of a domain name within an RDATA section has two impacts on signing and verification. The name must be decompressed and the the name must be set to lower case. This cannot be done at the same time - because the DNS specification requires that case be maintained. (I.e., a response is decompressed, saved for presentation and copied. The copy is lowered and verified.) There are four currently defined cases of domain names in RDATA's. There are those with none at all (e.g., TXT). There are those that start with one or two (NS, SOA). There are those that end with one or two (SRV, PX). The fourth category is the exceptions - those with name(s) in the middle. The lone member of this club is the cause for all of the trouble - SIG. Fortunately, a SIG record is not signed itself. I hope that as folks on this list read new RR proposals, we encourage others to make their formats fall into one of the first three categories (none, starts with, or ends with domain name[s]). ------- As far as the NXT bit map issue - I think it will be along time before it becomes a problem. We will have a long time to solve it. So I'd rather not wait to fix it before releasing the current code. With the current KEY and NXT formats, recall there are some manditorially 0 bits. In the KEY, flags bits 3 & 4 and in the the NXT, bit 0 of the field. (No type 0 stored). As John Gilmore suggested some time ago aith regards to the "number of questions" in the header, these manditorally 0 bits could be rebadged "version number" to distinguish formats - when we get better ideas. As someone who's spent many months coding to the RFC 2065 formats - and is not done yet - the last thing that will help my situation is to require me to go back and change everything I've done so far *and* still make headway into new pieces of code. I've had to do that for a previous employer, it doesn't make for a happy coder. I wouldn't mind if the solutions were required, but I'm not certain the new formats solve unworkable problems with the old formats. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Tue Jul 29 11:47:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA02178 for dns-security-outgoing; Tue, 29 Jul 1997 11:46:33 -0400 (EDT) Message-Id: Date: Tue, 29 Jul 97 07:43 PDT From: randy@psg.com (Randy Bush) To: John Gilmore Cc: Olafur Gudmundsson , dns-security@tis.com, dee@cybercash.com Subject: Re: Changes in DNSSEC specification, Request For Discussion References: <3.0.1.32.19970726170833.006e115c@pop.hq.tis.com> <199707282009.NAA04954@toad.com> Sender: owner-dns-security@ex.tis.com Precedence: bulk > DNSSEC is not a draft any more, it's a Proposed Standard. We can't > keep dinking around with it to our hearts' content. There are things > we would now like to change in IP and TCP and SMTP and SNMP and PPP > and lots of other protocols, but we live with them and the world is > much better off as a result. Red herring alert. The time to make changes based on implementation experience is now, between Proposed and Draft. Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. I am not speaking to whether the proposed changes are needed or not. I am merely trying to disabuse us of the notion that PSs should not be changed. randy From owner-dns-security Wed Jul 30 09:06:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA13117 for dns-security-outgoing; Wed, 30 Jul 1997 09:04:43 -0400 (EDT) From: gwc@deneb.firstunion.com (George Capehart) Message-Id: <199707292218.SAA06725@deneb.firstunion.com> Subject: Re: Changes in DNSSEC specification, Request For Discussion To: randy@psg.com (Randy Bush) Date: Tue, 29 Jul 1997 18:18:23 -0400 (EDT) Cc: dns-security@tis.com In-Reply-To: from "Randy Bush" at Jul 29, 97 07: 43:00 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk According to Randy Bush: > > > DNSSEC is not a draft any more, it's a Proposed Standard. We can't > > keep dinking around with it to our hearts' content. There are things > > we would now like to change in IP and TCP and SMTP and SNMP and PPP > > and lots of other protocols, but we live with them and the world is > > much better off as a result. > > Red herring alert. The time to make changes based on implementation > experience is now, between Proposed and Draft. > > Implementors should treat Proposed Standards as immature specifications. > It is desirable to implement them in order to gain experience and to > validate, test, and clarify the specification. However, since the > content of Proposed Standards may be changed if problems are found or > better solutions are identified, deploying implementations of such > standards into a disruption-sensitive environment is not recommended. > > I am not speaking to whether the proposed changes are needed or not. I am > merely trying to disabuse us of the notion that PSs should not be changed. > > randy > Agreed. IMHO, one of the strongest arguments for the PS step is that the opportunity to learn from the implementation process is valuable, if not essential. (Never _have_ been able to get a design perfect the first time . . .) :-}{ However, I *do* think that by the time a specification gets to the Draft Standard stage, it's a little late to be dinking with it . . . But then again, that's just my opinion, not that of my employer or anyone who will claim to know me. -- /* PGP ID: George Capehart , Key info on request * * "If you push something hard enough, it will fall over." * Fudd's First Law of Opposition */ From owner-dns-security Wed Jul 30 09:41:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA13420 for dns-security-outgoing; Wed, 30 Jul 1997 09:40:39 -0400 (EDT) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: <199707292218.SAA06725@deneb.firstunion.com> References: from "Randy Bush" at Jul 29, 97 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Jul 1997 09:39:35 -0400 To: gwc@deneb.firstunion.com (George Capehart) From: Edward Lewis Subject: Re: Changes in DNSSEC specification, Request For Discussion Cc: randy@psg.com (Randy Bush), dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 6:18 PM -0400 7/29/97, George Capehart wrote: >Agreed. IMHO, one of the strongest arguments for the PS step is that the >opportunity to learn from the implementation process is valuable, if not Besides the debate over whether a standard should be "dinked with" at a particular stage in the standard-cycle, is the issue of the immediacy (sp?) of the need for securing DNS. Are there any (external to my environment) calendar deadlines for "getting something out" with respect to DNSSEC? I can appreciate the desire of "wanting it now" but is there a time scale we should be aiming towards that might limit our "dinking distance?" -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Wed Jul 30 14:14:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA15406 for dns-security-outgoing; Wed, 30 Jul 1997 14:14:09 -0400 (EDT) Date: Wed, 30 Jul 1997 14:17:09 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Re: draft-ietf-dnssec-secext2-00.txt In-Reply-To: <7377.870041021@munnari.OZ.AU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk Hi, I've been on vacation for five days but I'm back now. (1) In this thread, as has been mentioned, the "labels" field has been made explicit in the ASCII form of SIG RR's, which all the implementors commenting seem to think is a good idea. One thing that helped convince me is that without this, it's iimpossible to print an RR with a bad labels values in debugging utilites like dig. So I assume this change should stay in. (2) On the NXT bit map questions, it is certainly a matter of judgement. If you look at the curve of assigned protocol numbers in the IPv4 header, you would predict the exhaustion of a byte worth, the expert opinion was that no more than a byte was needed in IPv6. The DNS Class field allocates two bytes but only three values have been used and it seems very unlikely that more than a handful of additional values will be used in the forseeable future, if that. DNS types do get assigned, but at a fairly slow rate. If someone wants to, they could go back through the Assigned Numbers RFC's and draw a graph and fit a curve to it. I believe that would show that there is little danger of exceeding one byte worth of type numbers in the next 10 years. And maybe the Kitchen Sink RR (or family of RRs) will take over some that would be new types. But then again, maybe a good reason will pop up to assign a bunch. Maybe there is a good read to assign RR Types with a first byte of 0xFE as name local, defined only relative to the owner name, and those with a first byte of 0xFD as zone local, defined only realtive to the zone they occur in (not that I am actually suggesting that nor am I offereing any solutions to the many problems it would casue). Keep in mind that the original Eastlake/Kaufman proposal was substantially more complex and tried super hard to pack bits and save space. The repeated feedback for the working group was that simplicity and, presumably, the simpler and easier and more rapid deployment that would result, was the way to go. Any change to NXT to accomodate sparse type number presence would be, as the code by Elz below shows, a substantial increase in complexity. At this point, I think we should be looking at getting the fastest deployment we can that does not box us into a corner or have significant implementation problems. Does the NXT bit map restrict us in the future? I guess so, although there is a question of judgement as to how serious a restriction it is and I previously did not consider it significant. Mulling over all the above, how about we go as follows: If the first bit of the current bit map area is zero, then it is interpreted as now. If the first byte is 0x80, it is defined as I specify below, all other first bytes with the top bit on are reservers (after all, maybe someday there will be a need for yet some other type existence/non-existence encoding...) The encoded form could be that below but I would prefer a series of one or more variable length blocks of 3 to 11 bytes. The first two bytes in each such block gives the byte offset in their top 13 bits (easy to mask to), the bottom three bits of the initial two bytes are the number of bytes of bit map except zero means nine. There would be no need to go to the encoded format until noticeably more RR types are allocated than at present. We should try to resolve this on the mailing list and in Munich. Unless there is rough consensus, paying particular attention to those doing the implementation, it shlud be left as is. Donald On Mon, 28 Jul 1997, Robert Elz wrote: > Date: Mon, 28 Jul 1997 08:03:41 +1000 > From: Robert Elz > To: dns-security@tis.com > Subject: Re: draft-ietf-dnssec-secext2-00.txt > > Date: Sat, 26 Jul 1997 17:23:39 -0400 > From: Olafur Gudmundsson > Message-ID: <3.0.1.32.19970726172339.006ebcf0@pop.hq.tis.com> > > > | >2. The NXT bit map > | > > | >The NXT RR currently uses a bit map of RR type numbers to represent a > | >set of RR types. Since RR type numbers are 16-bit unsigned integers, > | >this bit map may potentially become very large - up to 8192 bytes, > > | >As an alternative to the bit map representation, the RR types could be > | >represented as a list of (unique) 16-bit RR type numbers. > > If a change were to be desired, you want a combination of those two, not > one or the other - a simple list of 16 bit numbers could easily become > absurdly large, and in practice, probably quicker than a bit vector. > > If something else is wanted, perhaps a list of 32 bit structures, in which > the first byte is an offset multiple, and the other 24 bits are a bit > vector. It is kind of hard to describe in words how this works, so ... > > > l = ; /* an int */ > p = ; /* a char * or unsigned char */ > off = 0; /* an int */ > while (l >= 4) { > off += *(unsigned char *)p; > p++; > for (i = 0; i < 3; i++) { > for (j = 0; j < 7; j++) { > if (*p & (1 << j)) > printf("value %d found\n", > off * 24 + i * 8 + j; > } > p++; > } > off += 3; > l -= 4; > } > > The code is crude, and, of course not tested, so could have bugs, but I > think it describes what I mean better than I can in words. > > This way to represent all of the current 40 RR types would take 8 bytes, > an increase over the current 5, but not nearly as bad as the potential 80 > it would need with a list of 16 bit values (8 bytes there would be just > allow 4 RR types, which while about right, is probably not quite enough). > > This encoding also permits a gap of up to 6120 types to be skipped without > wasting anything at all (other than the 32 bits used to encode the 24 bits that > surround the value wanted), and gaps bigged than that just need one 32 bit > value for each 6120 RR numbers skipped - 40 bytes (10 * 4) would allow RR 65535 > to be represented (if no others are, or if the others that are happen to fall > in the words that need to be there). > > I'm not sure that this kind of complexity is needed, but I am fairly sure > that a list of RR types as individual numbers isn't the way to go. > > kre > > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-dns-security Wed Jul 30 15:17:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA15828 for dns-security-outgoing; Wed, 30 Jul 1997 15:16:38 -0400 (EDT) X-Sender: galvin@inside.east.commerce.net Message-Id: In-Reply-To: References: <7377.870041021@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 30 Jul 1997 15:26:40 -0400 To: dns-security@tis.com From: "James M. Galvin" Subject: Re: draft-ietf-dnssec-secext2-00.txt Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id PAA15825 Sender: owner-dns-security@ex.tis.com Precedence: bulk As Chair, let me make a few process observations. 1. We are not meeting in Munich. 2. The time to make technical changes to a specification is now, not later. Later the installed base will be significant and it won't be practical (or at least it will be like upgrading to IPv6). Keep in mind we're talking about an infrastructure protocol. 3. As far as I can tell, making the technical changes now will not slow down deployment to any significant degree. Sure, it will add a month to TIS's work (I'm not aware of any other complete or significant developers so if this really matters to you speak now or forever hold your peace) but what's a month considering how long it has taken us to get here. 4. Strictly speaking, changing the KEY RR should cause the document to recycle at Proposed. Frankly, though, I don't see this as an issue. TIS is going to do the right thing, more or less in real-time. I'm not aware of anyone else who really cares what the status of the document is. (If there is someone, speak up now, and speak specifically. I don't want vague generalities like nobody implements a Proposed standard only a Draft standard.) 5. I have not heard a compelling reason why the KEY RR should not be changed. To be compelling a reason must have some basis in objective fact and should probably come from a developer. TIS has made a proposal and as the only developers their opinion carries a great deal of weight. Opponents have a significant hurdle in my view, unless they've got an implementation. 6. I'll wait to see what if any discussion comes of Don's recent proposal on the NXT issue. Then, as soon as Don produces a revised document I'll issue a working group last call and we'll move on to the other documents this working group owns, to which we have not been giving any attention. Jim ---------------------------------------------------------------------------- James M. Galvin galvin@commerce.net CommerceNet +1 410.203.2707 3209A Corporate Court FAX +1 410.203.2709 Ellicott City, MD 21042 http://www.commerce.net/ From owner-dns-security Wed Jul 30 18:07:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA17044 for dns-security-outgoing; Wed, 30 Jul 1997 18:05:39 -0400 (EDT) Message-Id: <199707302214.PAA28837@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "James M. Galvin" cc: dns-security@tis.com, gnu@toad.com Subject: Re: draft-ietf-dnssec-secext2-00.txt In-reply-to: Date: Wed, 30 Jul 1997 15:14:12 -0700 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk > 3. As far as I can tell, making the technical changes now will not slow > down deployment to any significant degree. Sure, it will add a month to > TIS's work (I'm not aware of any other complete or significant developers > so if this really matters to you speak now or forever hold your peace) The only DNSSEC code running in production today was written by me. My code is in BIND-4.9.5 and BIND-8.1.1. There is no TIS code in there. My code was based on some secure update code donated by IBM. I guess there must be more than one developer. TIS has written a couple of good prototypes (and I hope to see another one from them soon). My job is turning their prototype code into production quality code for Paul Vixie. Questioning some of their design decisions (like whether to hope for unique key footprints, or make the code support duplicates) is part of the job. As a DNSSEC implementer and WG member, it's also part of my job to critique design proposals, such as the expansion of the flags field. > but what's a month considering how long it has taken us to get here. I've already addressed the downsides of delay (further bogus-RR mischief and security cracking; and the potential that our work is outlawed, making registrars who use DNSSEC felons in some countries). If we have a real reason to change the KEY RR then I support doing so. I'm willing to be convinced. The draft, which merely states the changes as fact, has not convinced me yet. I've already responded to Olafur's message giving rationales for the proposed changes. I see other ways to solve the problems described so far -- ways which do not require us to adopt incompatible changes. If we have real reasons to make *any* incompatible changes then it's good to let in some marginal ones (that might not have been worth it by themselves) at the same time. But we seem to have opened Pandora's box a bit, with most of the debate being about nits of marginal proposals, while the answers to more serious questions are simply assumed (like whether we should change anything at all, or whether we should require Diffie-Hellman signatures instead of RSA). > 5. I have not heard a compelling reason why the KEY RR should not be > changed. To be compelling a reason must have some basis in objective fact > and should probably come from a developer. TIS has made a proposal and as > the only developers their opinion carries a great deal of weight. > Opponents have a significant hurdle in my view, unless they've got an > implementation. This turns things on their head. There is an existing RFC; it seems to me that it would require a compelling reason to change it, rather than a compelling reason not to change it. > TIS has made a proposal and as > the only developers their opinion carries a great deal of weight. Design issues should not *always* be driven by programmers. My first mentor told me in 1973, "If your proposals keep focusing on the low-level bits you'll end up as badly misdirected as any implementer". Designs should not be cramped to fit the style of their first implementations. Olafur posted a request for discussion of the new draft (particularly the KEY RR changes) a few days ago. We're discussing them. I don't think it's time to railroad them through just yet... John From owner-dns-security Wed Jul 30 18:39:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA17194 for dns-security-outgoing; Wed, 30 Jul 1997 18:39:10 -0400 (EDT) Message-Id: <199707302247.PAA29465@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: dns-security@tis.com, gnu@toad.com Subject: Re: proposed SIG textual record change In-reply-to: Date: Wed, 30 Jul 1997 15:47:27 -0700 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk I see the proposed change in the textual format of the SIG record of marginal benefit. Even if the label field was explicit in the textual records, implementations should be checking that the specified number of labels matches the actual number of labels in the RR name, and printing a warning or error if they don't match. Thus they'll need access to the RR name anyway. If object-oriented implementations have trouble performing this check, perhaps they should rethink their object structure. Object orientation is no excuse for preventing subroutines from accessing information that they need to do a high quality job. If there is a concern that in the current SIG record, invalid label counts will not be visible, it is misplaced. When printing a SIG RR, if the label count doesn't match the actual number of labels on the RR name, BIND-4.9.X already prints a comment field containing a warning and the value of the labels field. This was changed in BIND-8, which dumps the entire RR in hex instead, with a comment about it being an invalid RR. I thought the earlier treatment was kinder, but I guess one of the BIND maintainers didn't want special code to pamper bogus RR's, once they had written the general case "invalid RR dump" code. John Gilmore From owner-dns-security Wed Jul 30 18:47:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA17240 for dns-security-outgoing; Wed, 30 Jul 1997 18:47:10 -0400 (EDT) Message-Id: <199707302255.PAA29584@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: dns-security@tis.com, gnu@toad.com Subject: Re: NXT record proposed changes Date: Wed, 30 Jul 1997 15:55:41 -0700 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk A small comment. The only immediate danger of having high-value RR types comes from Microsoft, which high-handedly assigned itself two RR types, 0xFF01 and 0xFF02, which we only discovered by examining packet dumps from Microsoft servers. I suggest that we need not consider the needs of people who ignore our standards processes while claiming to "Embrace and Extend". If it makes their NXT records huge, I say hurrah! John From owner-dns-security Thu Jul 31 22:24:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA27454 for dns-security-outgoing; Thu, 31 Jul 1997 22:20:11 -0400 (EDT) Date: Thu, 31 Jul 1997 22:28:35 -0400 Message-Id: <199708010228.WAA18036@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: John Gilmore Cc: "James M. Galvin" , dns-security@tis.com, gnu@toad.com In-Reply-To: John Gilmore's message of Wed, 30 Jul 1997 15:14:12 -0700, <199707302214.PAA28837@toad.com> Subject: Re: draft-ietf-dnssec-secext2-00.txt Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-dns-security@ex.tis.com Precedence: bulk Date: Wed, 30 Jul 1997 15:14:12 -0700 From: John Gilmore The only DNSSEC code running in production today was written by me. My code is in BIND-4.9.5 and BIND-8.1.1. There is no TIS code in there. My code was based on some secure update code donated by IBM. I guess there must be more than one developer. So it's in the latest released versions of BIND, eh? That's (in my opinion) a strong reason not to change things; otherwise the confusion resulting from the change is likely to set back the DNS deployment by quite a bit. John, how many sites would you estiate are actually using the DNS SEC features in BIND today? - Ted From owner-dns-security Thu Jul 31 22:47:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA27581 for dns-security-outgoing; Thu, 31 Jul 1997 22:44:42 -0400 (EDT) Message-Id: Date: Thu, 31 Jul 97 19:52 PDT From: randy@psg.com (Randy Bush) To: John Gilmore Cc: "James M. Galvin" , dns-security@tis.com Subject: Re: draft-ietf-dnssec-secext2-00.txt References: <199707302214.PAA28837@toad.com> Sender: owner-dns-security@ex.tis.com Precedence: bulk > This turns things on their head. There is an existing RFC; it seems > to me that it would require a compelling reason to change it, rather > than a compelling reason not to change it. What we should seek is technical and operational excellence and elegance, whether they require change or not. In that search longevity is an issue, though it often needs to be tempered with understanding of what possible futures are likely and which are our fantasies. My uneducated opinion is that new RR types seem to be generated rather frequently recently (whether they are used or useful is another discussion). And RR formats seem to change about once a decade. So, if we anticipate 40 to 80 new RR types in the lifetime of a KEY RR, what represenation is most efficient, both to transmit and to process? As far as size goes, I am more concerned about wire than disk, as I fear attack by packet shredders, congestion, ... randy