From owner-dns-security Fri Jan 2 11:15:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA13595 for dns-security-outgoing; Fri, 2 Jan 1998 11:10:21 -0500 (EST) Date: Fri, 2 Jan 1998 11:23:32 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Edward Lewis Cc: dns-security@tis.com Subject: Re: Another thought on Re: Proposed change to NXT In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk I agree that using hashes is more effort. But it is the only way I have seen thus far which allows you to deny names with cryptographic strength but not leak the names... Donald On Mon, 22 Dec 1997, Edward Lewis wrote: > Date: Mon, 22 Dec 1997 15:08:23 -0500 > From: Edward Lewis > To: dns-security@tis.com > Cc: Edward Lewis > Subject: Another thought on Re: Proposed change to NXT > > Including the hash of each name in the zone will double the number of names > in the zone, albeit with an equal number of records. This will have an > operational impact on the process of signing the data and the storing of > data. > > With the current NXT set up, I can do signing in four steps - two major and > two minor: > 1. Read params (easy) > 2. Ingest all data (hard) -- results in a sorted zone (b-tree in my case) > 3. Open up keys (easy) > 4. Process data - sign sets, add NXTs, write files. (hard) > > If the hashes are used, I will need to make a fifth step - placing the > adding of NXTs into their own step - before processing data. Hmmm. I may > need to use a different tree. > > The doubling of names may not be a big problem - the balanced b-tree adds > one more level across the board. Searching for a name averages one more > comparison. > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis Trusted Information Systems > Phone: +1 301-854-5794 Email: lewis@tis.com > > "Serenity now, insanity later" -- Lloyd Braun > > Opinions expressed are property of my evil twin, not my employer. > > > ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Fri Jan 2 11:44:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA13808 for dns-security-outgoing; Fri, 2 Jan 1998 11:44:20 -0500 (EST) Date: Fri, 2 Jan 1998 11:57:49 -0500 (EST) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Cc: "Donald E. Eastlake" Subject: Re: Proposed change to NXT Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk >From lewis@tis.comMon Dec 22 14:30:55 1997 >Date: Mon, 22 Dec 1997 11:49:24 -0500 >From: Edward Lewis >Subject: Re: Proposed change to NXT > >Olafur suggested I submit this segment of my proto-draft on the topic: > >3.0 Criterion for judging approaches > >Given the experience to date, a number of criteria have been >identified upon which to evaluate a replacement. These features >are not stated as "requirements" because absolute statements are >not possible in some cases (e.g., how is vulnerability quantized >in a general discussion?). > >The criteria of an authenticated non-existence solution are: > > The resolver should be able to determine that the response is > denying existence, and that the denial is the correct one. Don't all proposals so far for a response denying existence have an NXDOMAIN rcode? So it's is easy to tell that the response is denying the existence of a name. Proving that a response is proper and authentic is the trick. You need, for name denial, to not just prove that the requested name does not exist but also provably deny the existence of any wildcard that could have answered the question. (And when you provide an wildcard expanded result, you need to prove that the exact name did not exist.) > The denial of existance should not expose other names or data > in a zone. (RFC2065 failed this.) As far as I can tell, all proposals but the hashed one fail this criteria. (Hashed name NXTs do expose the number of distinct names but hides the names themselves.) > The approach should not require a private key to be used in a > name server machine. (Signing the response fails this.) Right, you can't sign the response data in real time. To achieve zone owner authority with signed responses, you would not only have to have the zone private key on-line at the primary, but also on-line at every secondary. > The approach should minimize vulnerablilies and not provide a > mechanism for an attack to deny existence of other data. > (The SOA response fails this.) (I don't consider this "suppy the SOA" as a serious proposal at all. It has nothing that I can see to do with providing cryptographic security for name denial.) The 2065 method of putting the end of a wildcard name scope in all NXTs whose owner names are within that wildcard scope permits a server to falsely deny the existence of names within that scope in return for not leaking names in that scope. (And its easy to add a zone wilde wildcard if you want to stop all name leakage in return for losing all ability to authenticatably deny names.) The TIS idea of permitting the zone name to appear in the RDATA portion of any NXT also has a similar problem in that a denial of a name lexcially after the last name in a zone can't be done because you can't tell if it is a genuine denial of that sort or just a reply from a zone where you are always using the zone name in the RDATA. (You can fix this and save a little space by using root in the RDATA in the TIS scheme instead of the zone name. Then you can always tell if the NXT RR is really trying to deny a name (and is leaking the bracketing names) or is from a zone where you have decided to not authoritatively deny names in return for not leaking them. However, you then have to make a special case of the root zone and say, for example, that the option of not leaking names is unavailable in the root zone so for any NXT whose owner name is a TLD, the RDATA is alway the really true next name, even if that is root. This does not seem too bad as there are a few special thing about the root zone anyway and there does not seem to be any reason to hide a TLD.) > The approach should minimize the additions to the DNS in terms > names and or resource records. Hashing doubles the number of names while other techniques do not. All proposals so far seem to be the same in number of resource records added and since you also need to be able to authoritatively deny the existence of types, seems like you have to have one RR per original owner name anyway so I don't see much difference between proposals in this regard. Note that the hashed proposal avoides the oddity of having two different NXTs with different signatures at delegation points. If you use the more detailed hashed proposal I suggested, the upper and lower NXTs at a delgation point would always have diffent owner names. >4.0 Taxonomy of Mechanisms (real and imagined) > >There are a few categories in which all of the considered mechanisms >fit. One category is "here's what I have, look to see if what you >want is here," the NXT is an example of this. Another is "I >tell you definitively that what you seek is not here" is where all >signed-response mechanims fall. Requiring the spreading the zone private key out to multiple servers (primary and all secondary) as a requirement seems much too dangerous to me so I don't see that zone owner signed reponses are a good idea. > The third is "there's nothing >in this range, which, as you can see, is where your data would be." >Returning the SOA is an example of this. Unless this response is signed by the zone owner, I just don't see that the SOA is worth any more than a non-secure DNS server response. If it is signed by the zone owner, then its the case above. >(If any other categories can be identified, please contribute.) > >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis Trusted Information Systems >Phone: +1 301-854-5794 Email: lewis@tis.com > >"Serenity now, insanity later" -- Lloyd Braun > >Opinions expressed are property of my evil twin, not my employer. Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Fri Jan 2 12:27:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14108 for dns-security-outgoing; Fri, 2 Jan 1998 12:27:21 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 2 Jan 1998 12:37:19 -0500 To: "Donald E. Eastlake 3rd" From: Edward Lewis Subject: Re: Another thought on Re: Proposed change to NXT Cc: Edward Lewis , dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 11:23 AM -0500 1/2/98, Donald E. Eastlake 3rd wrote: >I agree that using hashes is more effort. But it is the only way I have >seen thus far which allows you to deny names with cryptographic strength >but not leak the names... Hashes aren't "the only way" but so far nobody has a better approach. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Trying is the first step to failure." - Homer Simpson Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Fri Jan 2 12:27:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14107 for dns-security-outgoing; Fri, 2 Jan 1998 12:27:21 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 2 Jan 1998 12:35:19 -0500 To: "Donald E. Eastlake 3rd" From: Edward Lewis Subject: Re: Proposed change to NXT Cc: dns-security@tis.com, "Donald E. Eastlake" Sender: owner-dns-security@ex.tis.com Precedence: bulk At 11:57 AM -0500 1/2/98, Donald E. Eastlake 3rd wrote: >Don't all proposals so far for a response denying existence have an >NXDOMAIN rcode? So it's is easy to tell that the response is denying Unfortunately, no. Maybe this is a BINDism, but BIND returns RCODE = NOERROR when the name exists but the desired data set does not. This applies to all forms of denial - the full SOA, the signed SOA, and the empty response. (Yes, that's 6 variations.) >> The denial of existance should not expose other names or data >> in a zone. (RFC2065 failed this.) > >As far as I can tell, all proposals but the hashed one fail this >criteria. (Hashed name NXTs do expose the number of distinct names but >hides the names themselves.) FWIW, returning the signed SOA does not fail this. >> The approach should minimize vulnerablilies and not provide a >> mechanism for an attack to deny existence of other data. >> (The SOA response fails this.) > >(I don't consider this "suppy the SOA" as a serious proposal at all. It >has nothing that I can see to do with providing cryptographic security >for name denial.) I included the SOA return because it has been historically used and is in the current BIND distributions. Given that it has a much richer track record than any of the other proposals, I feel it is serious enough to warrant inclusion in a study. >The TIS idea of permitting the zone name to appear in the RDATA portion Hey! That's Olafur's - not mine! ;) I don't like that any more that the wildcard stunt. (They're the same thing.) >> The approach should minimize the additions to the DNS in terms >> names and or resource records. > >Hashing doubles the number of names while other techniques do not. All >proposals so far seem to be the same in number of resource records >added and since you also need to be able to authoritatively deny the That's not true - the SOA return adds no records. >Note that the hashed proposal avoides the oddity of having two different >NXTs with different signatures at delegation points. If you use the >more detailed hashed proposal I suggested, the upper and lower NXTs at >a delgation point would always have diffent owner names. Could you provide an example of this? I can't find the 'detailed' proposal to see how this is done. (I thought hash (name) always yielded the same value.) In any case, what's the problem of having multiple NXT's at a name? At a delegation point, the situation is very decideable - I can look at an NXT or SIG(NXT) and can determine whether it is upper or lower. (Providing, for the SIG, I follow a strict signature authorization policy such as DOWN.) >Requiring the spreading the zone private key out to multiple servers >(primary and all secondary) as a requirement seems much too dangerous >to me so I don't see that zone owner signed reponses are a good idea. That's obvious. I included the category for completeness. >Unless this response is signed by the zone owner, I just don't see that >the SOA is worth any more than a non-secure DNS server response. If it >is signed by the zone owner, then its the case above. Of course the SOA is signed. This is how the name server I am testing against works. The proto-draft proposes an admittedly weak attempt - basically extending the SOA idea for segments of the zone, such as all labels starting with 'a', 'b', etc. The idea doesn't leak the names in the zone or even the size of the zone, but adds records and names and isn't specific to a request. The approach is a compromise of proposals, I'm not sure its worth a draft unless there is no other workable solution. The reason I came up with the idea was that I feared that the hash wasn't good enough - I could precompute all combinations of names and then look at the returned hash values. Looking more at this, I'm less concerned about this kind of attack, although I'm not convinced. (I'm writing code for the signer still, so I'm thinking C and not math right now.) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Trying is the first step to failure." - Homer Simpson Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Tue Jan 6 14:53:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA16445 for dns-security-outgoing; Tue, 6 Jan 1998 14:46:37 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 6 Jan 1998 14:37:37 -0500 To: dns-security@tis.com From: Edward Lewis Subject: Proposal to the NXT issue Cc: lewis@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk I'd like to propose the following as an intermediate step towards resolving the NXT/name hiding issue. I propose that any new method of providing denial of existence be assigned a different type name/number than NXT/30. In addition - we should forge ahead with the current NXT in the current software and take on the issue of the name hiding NXT as a work group action item. This will allow the current implementation to go forward and be released. (This also allows the IETF documents to continue progressing towards full standard-dom.) The TIS writing of the reference code is facing diminishing resources and we need to turn or attention to other research tasks. Pragmatically, if there is a decision to specify a radically different approach to the NXT, it probably won't make it into our code anyhow. Disclaimer - I'm not saying TIS is out of DNSSEC, etc., etc., but I do know we have to start new tasks soon. We'll probably be able to maintain our code, but expanding it will be crimped unless directed to do so by our sponsor(s). Regardless, if we are to change the NXT, then no code should be released, lest we face the demons of compatibility. This has the unfortunate side effect of further delaying everything. By getting a different RR type for the NXT++ (ooh, whatever), we won't have compatibility problems. A resolver can determine how to process the data (whether to hash or not to hash) based on type. We can deprecate the NXT later if we wish to do so. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Trying is the first step to failure." - Homer Simpson Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Wed Jan 7 12:56:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA24676 for dns-security-outgoing; Wed, 7 Jan 1998 12:50:37 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 Jan 1998 12:51:00 -0500 To: dns-security@tis.com, ghd@cc.bellcore.com From: Edward Lewis Subject: ATMA records Cc: lewis@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk Does anyone know of a reference for the alleged ATMA RR? (Type # 34.) It's listed on the IANA DNS parameters page, but I haven't come across any document describing it. The page lists one address for the author (in the To: field of this message), but that's all. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Trying is the first step to failure." - Homer Simpson Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Wed Jan 7 13:13:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA24820 for dns-security-outgoing; Wed, 7 Jan 1998 13:11:37 -0500 (EST) Date: Wed, 7 Jan 1998 13:24:56 -0500 (EST) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Re: Proposed change to NXT In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Fri, 2 Jan 1998, Edward Lewis wrote: > Date: Fri, 2 Jan 1998 12:35:19 -0500 > From: Edward Lewis > Subject: Re: Proposed change to NXT > > At 11:57 AM -0500 1/2/98, Donald E. Eastlake 3rd wrote: > >Don't all proposals so far for a response denying existence have an > >NXDOMAIN rcode? So it's is easy to tell that the response is denying > > Unfortunately, no. Maybe this is a BINDism, but BIND returns RCODE = NOERROR > when the name exists but the desired data set does not. This applies to > all forms of denial - the full SOA, the signed SOA, and the empty response. > (Yes, that's 6 variations.) Well, I was talking about nonexistent names, not types. We need to keep these straight although a lot of the same considerations apply to both. > >> The denial of existance should not expose other names or data > >> in a zone. (RFC2065 failed this.) > > > >As far as I can tell, all proposals but the hashed one fail this > >criteria. (Hashed name NXTs do expose the number of distinct names but > >hides the names themselves.) > > FWIW, returning the signed SOA does not fail this. > > >> The approach should minimize vulnerablilies and not provide a > >> mechanism for an attack to deny existence of other data. > >> (The SOA response fails this.) > > > >(I don't consider this "supply the SOA" as a serious proposal at all. It > >has nothing that I can see to do with providing cryptographic security > >for name denial.) > > I included the SOA return because it has been historically used and is in > the current BIND distributions. Given that it has a much richer track > record than any of the other proposals, I feel it is serious enough to > warrant inclusion in a study. I have been assuming you meant return the SOA with its SIG but I guess you could mean some sort of server signature on the response. But in any case, the goal of dnssec is to provide authentication back to the zone owner. I don't think that the SOA with its SIG does this, since anyone can get these RRs and use them to forge false denials. I don't think server signing of a response with an SOA in it does this as anyone can get the SOA and you could be asking any server (some caching server you typically use, the server for an ancestor zone since you might not know about the intervening delgation(s) yet, some secondary, ...) and there is no particular reason to trust the server signature (even the primary sever's server signature isn't the zone owner's signature). So no matter which interpreation of "signed SOA" I use, I still just don't understand what it has to do with the type of cryptographicaly enforceable security back to the zone owner that dnssec seeks to achieve. > >The TIS idea of permitting the zone name to appear in the RDATA portion > > Hey! That's Olafur's - not mine! ;) I don't like that any more that the > wildcard stunt. (They're the same thing.) Sorry about any mis-attribution. While there may be some similarities, I don't consider the "can always put the zone name in the NXT RDATA" to be the same as the RFC2065 wildcard name scope NXT masking. Allowing the zone name to be used means that you can *never* cryptographically deny names that lexically fall after the last name in the zone. Because those NXT's *normally* have the zone name within their RDATA and you can't tell if the response to a query for a name off the end of the lexically ordered zone is genuine, because the name does not exist, or is just a case where the zone name was stuck in the RDATA to avoid name leakage. (I think this problem can be fixed by using root instead of the zone in the RDATA and adding a special rule that says leakage of all names in root is OK.) On the other hand, with the wildcard name scope masking, you have complete cryptographically verifiable denial for the zone, as long as there are no wildcards. And there are a lot of important zones with no wildcards (at least currently) such as root, the gTLDs, etc. > >> The approach should minimize the additions to the DNS in terms > >> names and or resource records. > > > >Hashing doubles the number of names while other techniques do not. All > >proposals so far seem to be the same in number of resource records > >added and since you also need to be able to authoritatively deny the > > That's not true - the SOA return adds no records. But as I say, I still don't understand what the SOA thing has to do with providing cryptographically verifiability traceable to the zone owner's key. > >Note that the hashed proposal avoides the oddity of having two different > >NXTs with different signatures at delegation points. If you use the > >more detailed hashed proposal I suggested, the upper and lower NXTs at > >a delgation point would always have diffent owner names. > > Could you provide an example of this? I can't find the 'detailed' proposal > to see how this is done. (I thought hash (name) always yielded the same > value.) For foo.com, in .com you would have hashfoocomhash.com while in foo.com you would have hashfoocomhash.foo.com where hashfoocomhash = whatever encoding is settled on of SHA1 ( foo.com ). > In any case, what's the problem of having multiple NXT's at a name? At a > delegation point, the situation is very decideable - I can look at an NXT > or SIG(NXT) and can determine whether it is upper or lower. (Providing, > for the SIG, I follow a strict signature authorization policy such as DOWN.) It's the only case where there are two different RSETs with the same owner name, separate SIG RRSETs covering them, etc., were you have to keep both around under many circumstances. Sure, you can figure out which is which, but it seems to me that this has to be a complicating special case. > >Requiring the spreading the zone private key out to multiple servers > >(primary and all secondary) as a requirement seems much too dangerous > >to me so I don't see that zone owner signed reponses are a good idea. > > That's obvious. I included the category for completeness. > > >Unless this response is signed by the zone owner, I just don't see that > >the SOA is worth any more than a non-secure DNS server response. If it > >is signed by the zone owner, then its the case above. > > Of course the SOA is signed. This is how the name server I am testing > against works. When I read the above I still wasn't completely sure if you meant the SOA in such a response has a SIG(SOA) or the response is signed somehow. > The proto-draft proposes an admittedly weak attempt - basically extending > the SOA idea for segments of the zone, such as all labels starting with > 'a', 'b', etc. The idea doesn't leak the names in the zone or even the > size of the zone, but adds records and names and isn't specific to a > request. The approach is a compromise of proposals, I'm not sure its worth > a draft unless there is no other workable solution. > > The reason I came up with the idea was that I feared that the hash wasn't > good enough - I could precompute all combinations of names and then look at > the returned hash values. Looking more at this, I'm less concerned about > this kind of attack, although I'm not convinced. (I'm writing code for the > signer still, so I'm thinking C and not math right now.) If the hash is of the FQDN, as I think it should be, then you have to do the hashing again for every level. And it's true that no protection is provided against an off line guessing attack. But people who want "secret" host names should pick longish random ones, just like people who want secret user ids or secret passwords. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis Trusted Information Systems > Phone: +1 301-854-5794 Email: lewis@tis.com > > "Trying is the first step to failure." - Homer Simpson > > Opinions expressed are property of my evil twin, not my employer. Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Wed Jan 7 14:52:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA25462 for dns-security-outgoing; Wed, 7 Jan 1998 14:50:41 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 Jan 1998 14:33:48 -0500 To: "Donald E. Eastlake 3rd" From: Edward Lewis Subject: Re: Proposed change to NXT Cc: dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 1:24 PM -0500 1/7/98, Donald E. Eastlake 3rd wrote: >On Fri, 2 Jan 1998, Edward Lewis wrote: >Well, I was talking about nonexistent names, not types. We need to keep >these straight although a lot of the same considerations apply to both. I don't see why there is a difference between non-existent name and non-existent data at a name - to the "eyes" of the resolver. In either case, the query is a failure. Is there a difference? >I have been assuming you meant return the SOA with its SIG but I guess you That's what I meant. E.g.: % dig somename.test txt returns: -----> test. SOA () test. SIG SOA ... >could mean some sort of server signature on the response. But in any case, >the goal of dnssec is to provide authentication back to the zone owner. I >don't think that the SOA with its SIG does this, since anyone can get these >RRs and use them to forge false denials. I don't think server signing of a I argue that the signed SOA does provide authentication back to the source, however, it is subject to the replay attack. The replay attack problem is the downfall of this approach - and is why other proposals have been made. Remember that I included the SOA/SIG(SOA) for consideration in a study to determine the criteria for a mechanism to supply the service of data denial of existence while maintaining data privacy. I am only stating that the SOA/SIG(SOA) is a mechanism. It is a mechanism that has the strongest track record to date but also suffers from a deficiency that warrants its replacement. >leakage. (I think this problem can be fixed by using root instead of the >zone in the RDATA and adding a special rule that says leakage of all >names in root is OK.) I'd like to limit the usage of "special rules." There are already too many artifical boundary cases unnecesarily introduced in the DNS software. > >For foo.com, in .com you would have hashfoocomhash.com while in foo.com >you would have hashfoocomhash.foo.com where hashfoocomhash = whatever >encoding is settled on of SHA1 ( foo.com ). Ok, I wasn't aware of the encoding. I would encourage a fairly detailed draft to be published on this approach, separate from the standards-track specification. >It's the only case where there are two different RSETs with the same >owner name, separate SIG RRSETs covering them, etc., were you have to >keep both around under many circumstances. Sure, you can figure out >which is which, but it seems to me that this has to be a complicating >special case. I guess I have my special cases and you have your special cases. ;) But the two NXTs is not a complication. (In the server, multiple copies of an RRSET are maintained for all sets - one that has completed the verification process and others that haven't. True, choosing which NXT to send is a type-specific decision.) >If the hash is of the FQDN, as I think it should be, then you have to do the >hashing again for every level. And it's true that no protection is provided >against an off line guessing attack. But people who want "secret" host names >should pick longish random ones, just like people who want secret user ids or >secret passwords. My concern is that the limitation of DNS names to 256 (in network format) bytes makes the "name space" not sparse enough for a brute force guessing game. I am not sure my concern is founded - assuming a brute for guess would need to try about 40 characters ( = 26 + 10 + enough to make a round number), the guesser would have to start from a field of about 40 to the 250th power names. Of course, expanding the length of the name in the hashing process makes the space more sparse. I dunno...like I say, this is just a concern. I'd still like to move this issue to another data type and let the current software go out as is. I'd like to have something out in use instead of continually making in-house improvements. I'm sure that my software will not be pleasing to use to everyone and I think it would be more efficient if I made changes to placate the throngs of users while also writing the code for the new NXT. (The code for the hashing is somewhat involved, but not hard, in the signer.) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Trying is the first step to failure." - Homer Simpson Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Wed Jan 7 16:19:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA25975 for dns-security-outgoing; Wed, 7 Jan 1998 16:17:46 -0500 (EST) Message-Id: <199801072129.QAA12827@hotsprings.american.com> X-Authentication-Warning: hotsprings.american.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.9 8/22/96 To: "Donald E. Eastlake 3rd" cc: dns-security@tis.com Subject: Re: Proposed change to NXT In-reply-to: Your message of "Wed, 07 Jan 1998 13:24:56 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Jan 1998 16:29:30 -0500 From: Josh Littlefield Sender: owner-dns-security@ex.tis.com Precedence: bulk Isn't one problem with the hash scheme the added difficulty in verifying you aren't being spoofed by the misapplication of a superzone NXT record? If I'm looking up abc.xyz.test.com, I night reasonably expect to receive NXT records owned by: HASHa.abc.xyz.test.com HASHb.xyz.test.com HASHc.test.com HASHd.com or none at all If I receive a (perfectly legitimate) NXT record at HASHd.com which specifies a range covering HASH(abc.xyz.test.com), then I have to do a bit of work to determine I shouldn't have instead been expecting a more specific NXT owner name. This is on top of whatever SIG checking which might need to be done. I suppose this checking invloves looking for NS records down the tree from the owner domain of the NXT record returned to the name in question. While this doesn't weaken the actual security of a proper implementation, it adds some implementation complexity that might be easily overlooked and is potentially costly. Both the opportunity for spoofing and the complexity of verification increase if we deploy more multi-level domains, as some IPv6 in-addr proposals, and Olafur's DBIT proposal, would suggest. Or do I have it all wrong? -josh ======================================================================== Josh Littlefield American Internet Corporation josh@american.com 4 Preston Court tel: 617-271-9200 fax: 617-275-4930 Bedford, MA 01730-2334 From owner-dns-security Wed Jan 7 16:48:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA26168 for dns-security-outgoing; Wed, 7 Jan 1998 16:47:02 -0500 (EST) From: Tim Larson Cc: dns-security@tis.com Message-ID: <34B3F6AB.33A7@buckeye.cb.lucent.com> Date: Wed, 07 Jan 1998 16:42:03 -0500 Original-From: Tim Larson Organization: Bell Laboratories Innovations for Lucent Technologies X-Mailer: Mozilla 3.01Gold (X11; U; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: Edward Lewis Original-CC: dns-security@tis.com Subject: Re: ATMA records References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk The ATMA record is defined in the ATM Forum (http://www.atmforum.com) document, "ATM Name System Specification Version 1.0" af-saa-0069.000 November, 1996 If you can get through to their FTP server, it's available in PDF format. The ATMA record RDATA is a 1-octet FORMAT plus a variable length address. The only defined FORMAT values are 0 (AESA) and 1 (E.164). Also, the ATMA.INT domain is defined for the PTR records. Tim Larson Lucent Technologies From owner-dns-security Thu Jan 8 09:50:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA02364 for dns-security-outgoing; Thu, 8 Jan 1998 09:48:11 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: <199801072129.QAA12827@hotsprings.american.com> References: Your message of "Wed, 07 Jan 1998 13:24:56 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 Jan 1998 09:25:39 -0500 To: Josh Littlefield From: Edward Lewis Subject: Re: Proposed change to NXT Cc: dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 4:29 PM -0500 1/7/98, Josh Littlefield wrote: >Isn't one problem with the hash scheme the added difficulty in verifying you >aren't being spoofed by the misapplication of a superzone NXT record? You certainly don't have it all wrong. I've made two attempts at writing a secure resolver and in each the work describe as needing to be done is in code. While "you're wrong" that its been overlooked (generous use of ;) needed here, you correct about the work and the load. In the non-hashed NXT case - which is all I can speak to now, here's what I did. For an NXT & SIG(NXT) return (and both are required for the check): Querying for name3.domain3.domain1./ns_t_type name1.domain2.domain1. NXT name2.domain4.domain1. bitmap SIG NXT (signer=) domain1. I'll use the following "variables" to try and make this simpler... Q (Query name) = name3.domain3.domain1. O (NXT Owner) = name1.domain2.domain1. N (Next name) = name2.domain4.domain1. S (NXT signer) = domain1. B (bitmap) = the NXT's bitmap, unspec'd here T (query type) = ns_t_type (The latter two only play a part if O == Q.) The NXT is the appropriate one if one of three cases are met: O < Q < N && Q is a member of S('s zone) O < Q && N == S && Q is a member of S O == Q && Q is a member of S && T is not a member of B The first case is the normal non-existant name, the middle case represents the non-existent name would have been after the last existent name in the zone, and the latter case is denial of a type for an existing name. These boolean equations assume that the zone "domain1." only signs appropriately configured records, i.e., than O and N are members of S. (If this assumption fails, no harm is done to the querier of Q/T. [1]) The "<" ordering for the checks are completely defined in RFC 2065 - more or less non-case sensitive alphabetic comparisons on equal depth labels. Whether T is a member of B is done by a bit check. The "Q is a member of S" is a bit trickier. Note that the checks so far do not require any queries other than those needed to verify the SIG(NXT)'s validity. Zone membership may require more queries. To check the membership, one must start at a zone whose information is trusted - KEY, NS, etc. It is necessary to creep down towards Q one label at a time. I look for the KEY record first and failing that, I then look for the NS set. I expext to see a zone key at the name S, along with all the trappings of a zone. Between S and Q (label-wise) I expect to see neither zone keys nor NS's. There's more detail in on the verification process. Now, how does this impact the hashing of NXT's? Well, maybe it doesn't, since I don't care that O and N are members of S. I can still carry out all the other checks, substituting H(?) for ? = O, Q, and N. Also H(S) when comparing to H(N). All I need to see is S unhashed, and it will be because it is in the sign-by field (starting at byte 18, starting at 0) in the SIG(NXT) RDATA. [1] If O and/or N are outside S but Q is inside S, then there is a misconfiguration at S - or it is being devious. In either case, since the query requested Q/T, and S is sending something other than Q/T - which spans over Q/T - then S is saying, in essence, "even if I had Q/T, I won't give it to you." There's no need to guarantee that O and/or N exist themselves. > >If I'm looking up abc.xyz.test.com, I night reasonably expect to receive NXT >records owned by: > HASHa.abc.xyz.test.com > HASHb.xyz.test.com > HASHc.test.com > HASHd.com > or none at all > >If I receive a (perfectly legitimate) NXT record at HASHd.com which specifies >a range covering HASH(abc.xyz.test.com), then I have to do a bit of work to >determine I shouldn't have instead been expecting a more specific NXT owner >name. This is on top of whatever SIG checking which might need to be done. > >I suppose this checking invloves looking for NS records down the tree from >the >owner domain of the NXT record returned to the name in question. > >While this doesn't weaken the actual security of a proper implementation, it >adds some implementation complexity that might be easily overlooked and is >potentially costly. Both the opportunity for spoofing and the complexity of >verification increase if we deploy more multi-level domains, as some IPv6 >in-addr proposals, and Olafur's DBIT proposal, would suggest. > >Or do I have it all wrong? > >-josh -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Trying is the first step to failure." - Homer Simpson Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Fri Jan 9 15:42:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13488 for dns-security-outgoing; Fri, 9 Jan 1998 15:35:37 -0500 (EST) Date: Fri, 9 Jan 1998 12:47:36 -0800 (PST) From: "Rick H. Wesson" To: dns-security@tis.com Subject: dns sec implementations Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk hello, where are the latest implementations of dnssec? thanks, -rick From owner-dns-security Thu Jan 15 18:17:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA07765 for dns-security-outgoing; Thu, 15 Jan 1998 18:14:17 -0500 (EST) Date: Thu, 15 Jan 1998 18:28:20 -0500 (EST) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: Re: Proposal to the NXT issue In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Tue, 6 Jan 1998, Edward Lewis wrote: > Date: Tue, 6 Jan 1998 14:37:37 -0500 > From: Edward Lewis > To: dns-security@tis.com > > I'd like to propose the following as an intermediate step towards resolving > the NXT/name hiding issue. > > I propose that any new method of providing denial of existence be assigned > a different type name/number than NXT/30. In addition - we should forge > ahead with the current NXT in the current software and take on the issue of > the name hiding NXT as a work group action item. > > This will allow the current implementation to go forward and be released. > (This also allows the IETF documents to continue progressing towards full > standard-dom.) I certainly want to get dnssec deployed soon. Since there is an escape bit in the NXT RR (the "RR type zero" bit of the bit map), perhaps that could be used rather than an unknown new RR type. It seems to me that this would make it more plausible that code could be made more forward compatible. > The TIS writing of the reference code is facing diminishing resources and > we need to turn or attention to other research tasks. Pragmatically, if > there is a decision to specify a radically different approach to the NXT, > it probably won't make it into our code anyhow. > > Disclaimer - I'm not saying TIS is out of DNSSEC, etc., etc., but I do know > we have to start new tasks soon. We'll probably be able to maintain our > code, but expanding it will be crimped unless directed to do so by our > sponsor(s). > > Regardless, if we are to change the NXT, then no code should be released, > lest we face the demons of compatibility. This has the unfortunate side > effect of further delaying everything. > > By getting a different RR type for the NXT++ (ooh, whatever), we won't have > compatibility problems. A resolver can determine how to process the data > (whether to hash or not to hash) based on type. I'm not sure how using a different RR type later helps that much. If we were to go with a new type, then code has to do something reasonable with a denial it gets back with no recognizable "nxt" like RRs accompanying it. I don't know how you could even start to block even the most blantant spoofing in that case. By using a variant of NXT later, there is still the possibility of spoofing, but at least you could give some return code saying that the response looks plausible and has NXTs, it is just that they are an NXT version you don't understand... > We can deprecate the NXT later if we wish to do so. > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis Trusted Information Systems > Phone: +1 301-854-5794 Email: lewis@tis.com > > "Trying is the first step to failure." - Homer Simpson > > Opinions expressed are property of my evil twin, not my employer. Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Thu Jan 15 21:21:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA08955 for dns-security-outgoing; Thu, 15 Jan 1998 21:20:20 -0500 (EST) Message-Id: <199801160231.SAA14907@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "Donald E. Eastlake 3rd" cc: dns-security@tis.com, gnu@toad.com Subject: Re: Security status of the root zone, and metaroot key In-reply-to: Date: Thu, 15 Jan 1998 18:31:27 -0800 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk Don Eastlake proposed: > RFC 2065 generally indicates that you tell whether a zone is secured by > checking its parent for a KEY entry at the delegation point, assuming the > parent is secure. This is a bit hard to do for root. Since it appears > that root will be secured quite early in the roll out of DNS security, I > propose to change the current secext2 draft to require that the root zone > always be secure. We don't know when the root zone will actually be secured. It depends on too many factors. Therefore I would not make that assumption in the draft. Instead, if the secure DNS implementation is configured with a metaroot public key then it's pretty certain that the root has been secured. I would suggest that this be the determining factor when the implementation is deciding whether records purportedly from the root zone need to be signed to be believed. Among the various operational alternatives, I believe that having a metaroot key, which signs the key for the root zone, permitting the key for the root zone to be changed, is the best way to roll out DNS Security at the root. Such a metaroot key would be stored in a very secure physical (alarmed vault) location, and only accessed once a year or so, to avoid exposing it to unwanted access. During that annual access, monthly signatures could be generated for the root key; these signatures could then be doled-out month by month in the DNS to certify the root key. The root key could be changed whenever desired, to discourage offline (e.g. factoring) attacks. The annual visit could generate or sign one or more backup root keys, again with monthly signatures, so that in case the root key is somehow compromised, a new one can be published without making an extraordinary access to the metaroot key. The metaroot key in the vault should be preserved on paper as well as on computer media, since the media we can write today may well be unreadable in ten or twenty years. We know how long paper and ink last, and where to find "drives" (eyes) that can read them. I would argue against using secret-sharing for the metaroot key, relying instead on physical vault secret-sharing (e.g. two physical keys or combinations required to open it). We don't have a reliable and widely used secret-sharing program -- that runs now, and will be maintained for the lifetime of the metaroot key. If that software breaks, which it will certainly do over the lifetime of the DNS, debugging it would reveal the metaroot private key anyway. We have to balance the risk of inadvertent copying of the key, with the risk of inadvertent loss of the key. Indications are that nobody in the world knows how to design a widely used, critical infrastructural public-key system whose top certifying key can be changed. Therefore we had better design it so we never need to change it, within the lifetime of the system (say 25-75 years). John Gilmore From owner-dns-security Fri Jan 16 11:17:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA13839 for dns-security-outgoing; Fri, 16 Jan 1998 11:13:23 -0500 (EST) Date: Fri, 16 Jan 1998 11:27:14 -0500 (EST) From: "Donald E. Eastlake 3rd" To: John Gilmore Cc: dns-security@tis.com Subject: Re: Security status of the root zone, and metaroot key In-Reply-To: <199801160231.SAA14907@toad.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Thu, 15 Jan 1998, John Gilmore wrote: > Date: Thu, 15 Jan 1998 18:31:27 -0800 > From: John Gilmore > Subject: Re: Security status of the root zone, and metaroot key > > Don Eastlake proposed: > > RFC 2065 generally indicates that you tell whether a zone is secured by > > checking its parent for a KEY entry at the delegation point, assuming the > > parent is secure. This is a bit hard to do for root. Since it appears > > that root will be secured quite early in the roll out of DNS security, I > > propose to change the current secext2 draft to require that the root zone > > always be secure. > > We don't know when the root zone will actually be secured. It depends > on too many factors. Therefore I would not make that assumption in the > draft. > > Instead, if the secure DNS implementation is configured with a > metaroot public key then it's pretty certain that the root has been > secured. I would suggest that this be the determining factor when the > implementation is deciding whether records purportedly from the root > zone need to be signed to be believed. Unless we want to allocate a flag bit for the purpose, there currently isn't any way to syntacticly distinguish the metaroot key from the regular root key. I suppose another alternative would be to always have a metaroot key but have it sign a null root key if root is not secured. All the indications I get are that root will be secured right away. > Among the various operational alternatives, I believe that having a > metaroot key, which signs the key for the root zone, permitting the > key for the root zone to be changed, is the best way to roll out DNS > Security at the root. Such a metaroot key would be stored in a very > secure physical (alarmed vault) location, and only accessed once a > year or so, to avoid exposing it to unwanted access. During that > annual access, monthly signatures could be generated for the root key; > these signatures could then be doled-out month by month in the DNS to > certify the root key. The root key could be changed whenever desired, > to discourage offline (e.g. factoring) attacks. The annual visit > could generate or sign one or more backup root keys, again with > monthly signatures, so that in case the root key is somehow > compromised, a new one can be published without making an > extraordinary access to the metaroot key. > > The metaroot key in the vault should be preserved on paper as well as > on computer media, since the media we can write today may well be > unreadable in ten or twenty years. We know how long paper and ink > last, and where to find "drives" (eyes) that can read them. > > I would argue against using secret-sharing for the metaroot key, > relying instead on physical vault secret-sharing (e.g. two physical > keys or combinations required to open it). We don't have a reliable > and widely used secret-sharing program -- that runs now, and will be > maintained for the lifetime of the metaroot key. If that software > breaks, which it will certainly do over the lifetime of the DNS, > debugging it would reveal the metaroot private key anyway. We have > to balance the risk of inadvertent copying of the key, with the risk > of inadvertent loss of the key. K.I.S.S. > Indications are that nobody in the world knows how to design a widely > used, critical infrastructural public-key system whose top certifying > key can be changed. Therefore we had better design it so we never > need to change it, within the lifetime of the system (say 25-75 > years). > > John Gilmore Thanks, Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Fri Jan 16 15:24:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA15588 for dns-security-outgoing; Fri, 16 Jan 1998 15:22:29 -0500 (EST) Date: Fri, 16 Jan 1998 15:36:04 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Josh Littlefield Cc: dns-security@tis.com Subject: Re: Proposed change to NXT In-Reply-To: <199801072129.QAA12827@hotsprings.american.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Wed, 7 Jan 1998, Josh Littlefield wrote: > Date: Wed, 07 Jan 1998 16:29:30 -0500 > From: Josh Littlefield > To: "Donald E. Eastlake 3rd" > > Isn't one problem with the hash scheme the added difficulty in verifying you > aren't being spoofed by the misapplication of a superzone NXT record? Hummm, this seems to be a good point. > If I'm looking up abc.xyz.test.com, I night reasonably expect to receive NXT > records owned by: > HASHa.abc.xyz.test.com > HASHb.xyz.test.com > HASHc.test.com > HASHd.com > or none at all > > If I receive a (perfectly legitimate) NXT record at HASHd.com which specifies > a range covering HASH(abc.xyz.test.com), then I have to do a bit of work to > determine I shouldn't have instead been expecting a more specific NXT owner > name. This is on top of whatever SIG checking which might need to be done. > > I suppose this checking invloves looking for NS records down the tree from the > owner domain of the NXT record returned to the name in question. Well, without hashing, it's not too hard to check that the NXT spanning the lexical part of the name space with the name in it does not have an NS record at it by looking at the bit map. If the supposedly non-existent name is the owner name of the NXT with one or more labels tacked on and there is an NS, you know you need to go deeper. So with the current proposal, high level NXTs are not a problem. But with hashed NXTs, checking for NS doesn't work because the owner name has this hash in it that might be any name in the zone, so you can't tell if it is a parent of the name you are looking for. So you need to do checking as you suggest if the possible non-existent name is more than one level below the purported local zone name in the NXT returned for the hashed scheme... > While this doesn't weaken the actual security of a proper implementation, it > adds some implementation complexity that might be easily overlooked and is > potentially costly. Both the opportunity for spoofing and the complexity of > verification increase if we deploy more multi-level domains, as some IPv6 > in-addr proposals, and Olafur's DBIT proposal, would suggest. There are plenty of multi-level domains out there. May country domains are multiple level as are many orgnaizations domains. > Or do I have it all wrong? No, I think you brought up a good point... > -josh > > ======================================================================== > Josh Littlefield American Internet Corporation > josh@american.com 4 Preston Court > tel: 617-271-9200 fax: 617-275-4930 Bedford, MA 01730-2334 Thanks, Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Mon Jan 19 10:17:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA06080 for dns-security-outgoing; Mon, 19 Jan 1998 10:11:46 -0500 (EST) Message-Id: <199801191445.JAA15024@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: dns-security@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-dnssec-ddi-03.txt Date: Mon, 19 Jan 1998 09:45:46 -0500 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 : Detached Domain Name System (DNS) Information Author(s) : D. Eastlake Filename : draft-ietf-dnssec-ddi-03.txt Pages : 8 Date : 16-Jan-98 A standard format is defined for representing detached DNS information. This is anticipated to be of use for storing information retrieved from the Domain Name System (DNS), including security information, in archival contexts or contexts not connected to the Internet. 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-ddi-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-ddi-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-ddi-03.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: <19980116162307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-ddi-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-ddi-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980116162307.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security Mon Jan 19 14:38:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA07731 for dns-security-outgoing; Mon, 19 Jan 1998 14:36:56 -0500 (EST) Message-Id: <199801191948.LAA12697@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: ddi-03, Secure Update, and SIG "validity period" In-reply-to: <199801191445.JAA15024@ns.ietf.org> Date: Mon, 19 Jan 1998 11:48:52 -0800 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk + However, if + the detached information is accompanied by SIG RRs, its validity + period is indicated in those SIG RRs so the retrieval time might be + of secondary importance. Actually the SIG RR's contain a "time signed" and a "signature expiration", both of which are absolute times. However, these values are nowhere defined to be "the validity period" of the signature. In particular, a key might not be valid at the instant it is signed; it may be intended for future use. For example, you might want to generate a signature in mid-January that validates a KEY RRset to be used for the month of March. It would not be published into the DNS until Feb 29 (or March 1), but it might have been generated weeks or months earlier (the last time we were at the secret vault under Cheyenne Mountain that holds our private key). If some miscreant steals this SIG record from us and tries to publish it on January 28, it should be rejected by recipients. This suggests that the DNSSEC I-D be explicitly changed to rename the "time signed" field as the "signature validity starting time" and the "signature expiration" field as the "signature validity ending time". It was never clear to me why we wanted to know exactly what time a SIG RR was generated anyway, unless it's to document what "random" time bits were being fed into a poor random number generator to generate the DSS signature :-(. At the moment, secext2-02 says: The "time signed" field is an unsigned number of seconds since the start of 1 January 1970, GMT, ignoring leap seconds. SIG RRs SHOULD NOT have a date signed more than a few days in the future. To prevent misordering of network requests to update a zone dynamically, monotonically increasing "time signed" dates may be necessary. This seems to be a non sequiter. What it probably means to say is: The "time signed" field is an unsigned number of seconds since the start of 1 January 1970, GMT, ignoring leap seconds. Zones that depend on secure dynamic update probably should not publish SIG RRs with a date signed more than a few days in the future, since monotonically increasing "time signed" dates may be necessary to prevent misordering of network requests to update a zone dynamically. Even this appears to say too much. I think they're only talking about the SIG RR that covers the zone's SOA record. Other SIG RR's could have any "time signed" that suits the zone owner. And furthermore, rather than say what "probably" "may be necessary", we should resolve the technical issue of what constraints on SIG validity periods (and on which RRsets) the secure dynamic update protocol actually requires, and state that. Someone who is following Secure Update more closely than I should look this over. John From owner-dns-security Wed Jan 21 11:17:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA24222 for dns-security-outgoing; Wed, 21 Jan 1998 11:12:20 -0500 (EST) Date: Wed, 21 Jan 1998 11:26:26 -0500 (EST) From: "Donald E. Eastlake 3rd" To: John Gilmore Cc: dns-security@tis.com Subject: Re: ddi-03, Secure Update, and SIG "validity period" In-Reply-To: <199801191948.LAA12697@toad.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Mon, 19 Jan 1998, John Gilmore wrote: > Date: Mon, 19 Jan 1998 11:48:52 -0800 > From: John Gilmore > To: dns-security@tis.com, gnu@toad.com > Subject: Re: ddi-03, Secure Update, and SIG "validity period" > > + However, if > + the detached information is accompanied by SIG RRs, its validity > + period is indicated in those SIG RRs so the retrieval time might be > + of secondary importance. > > Actually the SIG RR's contain a "time signed" and a "signature > expiration", both of which are absolute times. However, these values > are nowhere defined to be "the validity period" of the signature. In > particular, a key might not be valid at the instant it is signed; it > may be intended for future use. The filed name "time signed" was assigned a long time ago. > For example, you might want to generate a signature in mid-January > that validates a KEY RRset to be used for the month of March. It > would not be published into the DNS until Feb 29 (or March 1), but it > might have been generated weeks or months earlier (the last time we > were at the secret vault under Cheyenne Mountain that holds our > private key). If some miscreant steals this SIG record from us and > tries to publish it on January 28, it should be rejected by > recipients. > > This suggests that the DNSSEC I-D be explicitly changed to rename the > "time signed" field as the "signature validity starting time" and the > "signature expiration" field as the "signature validity ending time". > It was never clear to me why we wanted to know exactly what time a SIG > RR was generated anyway, unless it's to document what "random" time > bits were being fed into a poor random number generator to generate > the DSS signature :-(. I agree. Does anyone object? It would be nice to have a short name, like "signature inception". > At the moment, secext2-02 says: > > The "time signed" field is an unsigned number of seconds since the > start of 1 January 1970, GMT, ignoring leap seconds. SIG RRs SHOULD > NOT have a date signed more than a few days in the future. To > prevent misordering of network requests to update a zone dynamically, > monotonically increasing "time signed" dates may be necessary. > > This seems to be a non sequiter. What it probably means to say is: > > The "time signed" field is an unsigned number of seconds since the > start of 1 January 1970, GMT, ignoring leap seconds. Zones that > depend on secure dynamic update probably should not publish SIG RRs > with a date signed more than a few days in the future, since > monotonically increasing "time signed" dates may be necessary to > prevent misordering of network requests to update a zone > dynamically. > > Even this appears to say too much. I think they're only talking about > the SIG RR that covers the zone's SOA record. Other SIG RR's could > have any "time signed" that suits the zone owner. > > And furthermore, rather than say what "probably" "may be necessary", > we should resolve the technical issue of what constraints on SIG > validity periods (and on which RRsets) the secure dynamic update > protocol actually requires, and state that. Such things should be in the dynamic update RFC but I added the above langaute to the main DNSSEC RFC at the request of TIS. > Someone who is following Secure Update more closely than I should look > this over. > > John Thanks, Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Wed Jan 21 17:52:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA27366 for dns-security-outgoing; Wed, 21 Jan 1998 17:51:35 -0500 (EST) Message-Id: <199801212303.PAA22997@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "Donald E. Eastlake 3rd" Cc: dns-security@tis.com, gnu@toad.com Subject: Re: SIG "validity period" In-reply-to: Date: Wed, 21 Jan 1998 15:03:21 -0800 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk At the moment the TIS prototype identifies keys by the RRset name, algorithm, and key fingerprint. This formulation is used in zone files (to say what key should sign them), arguments to programs, etc. I found this quite cumbersome in actual use, and have been looking for an alternative model. I now have the glimmerings of one: > For example, you might want to generate a signature in mid-January > that validates a KEY RRset to be used for the month of March. It > would not be published into the DNS until Feb 29 (or March 1), but it > might have been generated weeks or months earlier (the last time we > were at the secret vault under Cheyenne Mountain that holds our > private key). I'm leaning toward structuring the human interface around periodicity. In general crypto use, and in DNSSEC, keys and the signatures generated with them must be changed periodically for good security. For many people, the period might be a month. This provides a handle for naming keys and signatures, that people can easily understand. E.g. I might ask that a zone be signed by the "March '98 toad.com" key, or by the "99Q1 root key" or the "2001 Week 5 key for TIS.COM". So a site might be able to decide that it'll change its zone key once a year, generate signatures on that key which last five weeks, and refresh those signatures once a month. Every month they'd sign with the next month's zone key (which would be the same 11 months out of 12). The results of that signing would be published on their domain server at the start of the next month. The user interface would all be in those terms, i.e. "Sign zone with next period's key", and the code would keep track of what the periods were. Nobody has defined the interactions from zone to superzone yet. These would need to be periodic, since all signatures expire sometime, and prudent signatures expire soon (since there's no recovation in DNSSEC). (You can very quickly stop publishing a long-term signature, but you can't stop people from replaying it if they kept a copy). Since millions of zones will have a superzone like .COM, these interactions will have to be automated, yet secure. And .COM may change its key with a different periodicity than the subzone. Compromised keys at either level may result in needing to resign quickly, to limit the damage. It may be prudent for a superzone to always sign a subzone with two keys -- one of which is not yet signed by ITS parent -- so that if the superzone key is compromised, the subzone already has a signature by a replacement key, which would start working as soon as it was published and made part of the cert chain. I haven't fleshed these ideas out in C code and proposed operational procedures yet. I'm interested in your reactions. John From owner-dns-security Wed Jan 21 18:27:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA27580 for dns-security-outgoing; Wed, 21 Jan 1998 18:27:36 -0500 (EST) Date: Wed, 21 Jan 1998 18:42:07 -0500 (EST) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: new main draft Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk I have submitted a new version of the main draft. It is available at Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Thu Jan 22 05:15:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA01315 for dns-security-outgoing; Thu, 22 Jan 1998 05:14:37 -0500 (EST) Organization: ESAT, K.U.Leuven, Belgium Message-Id: <2.2.32.19980122102717.0075bcac@mailserv.esat.kuleuven.ac.be> X-Sender: fmertens@mailserv.esat.kuleuven.ac.be X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Jan 1998 11:27:17 +0100 To: dns-security@tis.com From: Filip Mertens Subject: test just ignore Sender: owner-dns-security@ex.tis.com Precedence: bulk filip.mertens@esat.kuleuven.ac.be From owner-dns-security Thu Jan 22 06:29:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA01665 for dns-security-outgoing; Thu, 22 Jan 1998 06:28:35 -0500 (EST) Organization: ESAT, K.U.Leuven, Belgium Message-Id: <2.2.32.19980122114231.0075c294@mailserv.esat.kuleuven.ac.be> X-Sender: fmertens@mailserv.esat.kuleuven.ac.be X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Jan 1998 12:42:31 +0100 To: dns-security@tis.com From: Filip Mertens Subject: 2nd test Sender: owner-dns-security@ex.tis.com Precedence: bulk filip.mertens@esat.kuleuven.ac.be From owner-dns-security Thu Jan 22 12:13:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA04470 for dns-security-outgoing; Thu, 22 Jan 1998 12:06:39 -0500 (EST) Date: Thu, 22 Jan 1998 12:19:22 -0500 (EST) From: "Donald E. Eastlake 3rd" To: John Gilmore Cc: dns-security@tis.com, "Donald E. Eastlake" Subject: Re: SIG "validity period" In-Reply-To: <199801212303.PAA22997@toad.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk These seem like good ideas. You might also want to look at Section 4.5 of secext2-03 which gives a hypothetical scenario for root key rollover where you always have two root keys in root. I would think that most zones would not have to go that far and would, at worst, just have a brief overlap when they rolled over their zone key. Donald On Wed, 21 Jan 1998, John Gilmore wrote: > Date: Wed, 21 Jan 1998 15:03:21 -0800 > From: John Gilmore > To: "Donald E. Eastlake 3rd" > Cc: dns-security@tis.com, gnu@toad.com > Subject: Re: SIG "validity period" > > At the moment the TIS prototype identifies keys by the RRset name, > algorithm, and key fingerprint. This formulation is used in zone > files (to say what key should sign them), arguments to programs, etc. > I found this quite cumbersome in actual use, and have been looking for > an alternative model. > > I now have the glimmerings of one: > > > For example, you might want to generate a signature in mid-January > > that validates a KEY RRset to be used for the month of March. It > > would not be published into the DNS until Feb 29 (or March 1), but it > > might have been generated weeks or months earlier (the last time we > > were at the secret vault under Cheyenne Mountain that holds our > > private key). > > I'm leaning toward structuring the human interface around periodicity. > In general crypto use, and in DNSSEC, keys and the signatures > generated with them must be changed periodically for good security. > For many people, the period might be a month. This provides a handle > for naming keys and signatures, that people can easily understand. > E.g. I might ask that a zone be signed by the "March '98 toad.com" > key, or by the "99Q1 root key" or the "2001 Week 5 key for TIS.COM". > > So a site might be able to decide that it'll change its zone key once > a year, generate signatures on that key which last five weeks, and > refresh those signatures once a month. Every month they'd sign with > the next month's zone key (which would be the same 11 months out of > 12). The results of that signing would be published on their domain > server at the start of the next month. The user interface would all be > in those terms, i.e. "Sign zone with next period's key", and the code > would keep track of what the periods were. > > Nobody has defined the interactions from zone to superzone yet. These > would need to be periodic, since all signatures expire sometime, and > prudent signatures expire soon (since there's no recovation in > DNSSEC). (You can very quickly stop publishing a long-term signature, > but you can't stop people from replaying it if they kept a copy). > Since millions of zones will have a superzone like .COM, these > interactions will have to be automated, yet secure. And .COM may > change its key with a different periodicity than the subzone. > Compromised keys at either level may result in needing to resign > quickly, to limit the damage. It may be prudent for a superzone to > always sign a subzone with two keys -- one of which is not yet signed > by ITS parent -- so that if the superzone key is compromised, the > subzone already has a signature by a replacement key, which would > start working as soon as it was published and made part of the cert > chain. > > I haven't fleshed these ideas out in C code and proposed operational > procedures yet. I'm interested in your reactions. > > John ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Fri Jan 23 08:12:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA12255 for dns-security-outgoing; Fri, 23 Jan 1998 08:09:53 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: References: <199801191948.LAA12697@toad.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 Jan 1998 07:51:03 -0500 To: "Donald E. Eastlake 3rd" From: Edward Lewis Subject: Re: ddi-03, Secure Update, and SIG "validity period" Cc: John Gilmore , dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 11:26 AM -0500 1/21/98, Donald E. Eastlake 3rd wrote: >> It was never clear to me why we wanted to know exactly what time a SIG >> RR was generated anyway, unless it's to document what "random" time >> bits were being fed into a poor random number generator to generate >> the DSS signature :-(. > >I agree. Does anyone object? I don't care, but the signer code I'm wrapping up sets the time signed field to the value of a time() call at the beginning of the signing phase. The software does not give the user an option to change that. It wouldn't be hard to write the code, but I'm past the point of adding new functionality. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com "Trying is the first step to failure." - Homer Simpson Opinions expressed are property of my evil twin, not my employer. From owner-dns-security Fri Jan 23 08:47:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA12519 for dns-security-outgoing; Fri, 23 Jan 1998 08:46:51 -0500 (EST) Date: Fri, 23 Jan 1998 09:00:48 -0500 (EST) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Subject: draft-eitf-dnssec-ddi-04.txt Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk I submitted an update to the ddi draft. The only change is to strighten out some errors in when the top byte of the number of seconds since 1970 exceeds various values. The old version had some numbers based on seconds since 1900. Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Mon Jan 26 09:43:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA07397 for dns-security-outgoing; Mon, 26 Jan 1998 09:36:09 -0500 (EST) Date: Mon, 26 Jan 1998 09:50:02 -0500 (EST) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com Cc: John Gilmore , "Donald E. Eastlake" Subject: Re: Security status of the root zone, and metaroot key (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk The current DNSSEC proposal specifically contemplates that a resolver might not have a root key or meta-key configured because it is intended that it climb the DNS tree to root. For example, it might be inside some company's enclave and they might wish it to depend on the upward key provided by their border DNS servers. (Come to think of it, the secext2 draft should probably say that if the parent zone of secure zone Z is insecure and there will be resovlers staticly configured with the public key for zone Z or a secure child of Z, then the servers for zone Z should be staticly configured with a null KEY for the parent zone, signed by zone Z...) Admitted, the meta-root key is supposed to be a realy long term key and is supposed to "never" be compromosed. Still, I think the right thing to do if root is insecure would be to just make up a mera-root key and staticly configure a null KEY for root signed by this made up meta-root key rather than depending on the presence or absence of a meta-root key. Donald =================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc ---------- Forwarded message ---------- Date: Fri, 16 Jan 1998 11:27:14 -0500 (EST) From: Donald E. Eastlake 3rd To: John Gilmore Cc: dns-security@tis.com Subject: Re: Security status of the root zone, and metaroot key On Thu, 15 Jan 1998, John Gilmore wrote: > Date: Thu, 15 Jan 1998 18:31:27 -0800 > From: John Gilmore > Subject: Re: Security status of the root zone, and metaroot key > > Don Eastlake proposed: > > RFC 2065 generally indicates that you tell whether a zone is secured by > > checking its parent for a KEY entry at the delegation point, assuming the > > parent is secure. This is a bit hard to do for root. Since it appears > > that root will be secured quite early in the roll out of DNS security, I > > propose to change the current secext2 draft to require that the root zone > > always be secure. > > We don't know when the root zone will actually be secured. It depends > on too many factors. Therefore I would not make that assumption in the > draft. > > Instead, if the secure DNS implementation is configured with a > metaroot public key then it's pretty certain that the root has been > secured. I would suggest that this be the determining factor when the > implementation is deciding whether records purportedly from the root > zone need to be signed to be believed. Unless we want to allocate a flag bit for the purpose, there currently isn't any way to syntacticly distinguish the metaroot key from the regular root key. I suppose another alternative would be to always have a metaroot key but have it sign a null root key if root is not secured. All the indications I get are that root will be secured right away. > Among the various operational alternatives, I believe that having a > metaroot key, which signs the key for the root zone, permitting the > key for the root zone to be changed, is the best way to roll out DNS > Security at the root. Such a metaroot key would be stored in a very > secure physical (alarmed vault) location, and only accessed once a > year or so, to avoid exposing it to unwanted access. During that > annual access, monthly signatures could be generated for the root key; > these signatures could then be doled-out month by month in the DNS to > certify the root key. The root key could be changed whenever desired, > to discourage offline (e.g. factoring) attacks. The annual visit > could generate or sign one or more backup root keys, again with > monthly signatures, so that in case the root key is somehow > compromised, a new one can be published without making an > extraordinary access to the metaroot key. > > The metaroot key in the vault should be preserved on paper as well as > on computer media, since the media we can write today may well be > unreadable in ten or twenty years. We know how long paper and ink > last, and where to find "drives" (eyes) that can read them. > > I would argue against using secret-sharing for the metaroot key, > relying instead on physical vault secret-sharing (e.g. two physical > keys or combinations required to open it). We don't have a reliable > and widely used secret-sharing program -- that runs now, and will be > maintained for the lifetime of the metaroot key. If that software > breaks, which it will certainly do over the lifetime of the DNS, > debugging it would reveal the metaroot private key anyway. We have > to balance the risk of inadvertent copying of the key, with the risk > of inadvertent loss of the key. K.I.S.S. > Indications are that nobody in the world knows how to design a widely > used, critical infrastructural public-key system whose top certifying > key can be changed. Therefore we had better design it so we never > need to change it, within the lifetime of the system (say 25-75 > years). > > John Gilmore Thanks, Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Tue Jan 27 07:27:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA16784 for dns-security-outgoing; Tue, 27 Jan 1998 07:26:26 -0500 (EST) Message-Id: <199801271130.GAA06567@tapas.nixu.fi> X-Mailer: exmh version 2.0zeta 7/24/97 To: dns-security@tis.com cc: lea@tapas.nixu.fi Subject: DNSSEC, CNAME & forthcoming CERTs Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Jan 1998 06:30:58 -0500 From: Lea Viljanen Sender: owner-dns-security@ex.tis.com Precedence: bulk Are there any plans to allow CERT records to be attached to a CNAME in the new DNSSEC draft (cf. the KEY and SIG records)? I know it's not very sensible to refer to a RR which is not yet completed, but could the wording be changed to reflect the idea of allowing security related RRs with a CNAME? -- Lea 'LadyBug' Viljanen NameSurfer Ltd Lea.Viljanen@namesurfer.com WWW-based DNS-tools From owner-dns-security Tue Jan 27 09:48:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA17964 for dns-security-outgoing; Tue, 27 Jan 1998 09:45:31 -0500 (EST) Message-Id: <199801271451.JAA05427@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: dns-security@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-dnssec-ddi-04.txt Date: Tue, 27 Jan 1998 09:51:24 -0500 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 : Detached Domain Name System (DNS) Information Author(s) : D. Eastlake Filename : draft-ietf-dnssec-ddi-04.txt Pages : 8 Date : 26-Jan-98 A standard format is defined for representing detached DNS information. This is anticipated to be of use for storing information retrieved from the Domain Name System (DNS), including security information, in archival contexts or contexts not connected to the Internet. 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-ddi-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-ddi-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-ddi-04.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: <19980126142624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-ddi-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-ddi-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980126142624.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security Tue Jan 27 09:52:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA18036 for dns-security-outgoing; Tue, 27 Jan 1998 09:52:31 -0500 (EST) Date: Tue, 27 Jan 1998 10:05:32 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Lea Viljanen Cc: dns-security@tis.com Subject: Re: DNSSEC, CNAME & forthcoming CERTs In-Reply-To: <199801271130.GAA06567@tapas.nixu.fi> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk Why do you want this? A CNAME indicates that you are looking up an alternative / old / wrong name for something and point to the canonical name. NXT and SIG RR's are allowed at the same name as a CNAME to secure that CNAME. KEY RR's are allowed at a CNAME only for the case where the zone is delegating authorith to some entity with that name and that entity decided to CNAME itself to some other name. Under the common circumstance where a zone is all signed by the zone owner using a zone key, there would be no KEY RR's at CNAMEs. CERT RR's and not used in securing the DNS so a CERT at a CNAME to secure the CNAME does not seem to make sense... Donald On Tue, 27 Jan 1998, Lea Viljanen wrote: > Date: Tue, 27 Jan 1998 06:30:58 -0500 > From: Lea Viljanen > To: dns-security@tis.com > Cc: lea@tapas.nixu.fi > Subject: DNSSEC, CNAME & forthcoming CERTs > > > Are there any plans to allow CERT records to be attached to > a CNAME in the new DNSSEC draft (cf. the KEY and SIG records)? > > I know it's not very sensible to refer to a RR which is > not yet completed, but could the wording be changed to reflect > the idea of allowing security related RRs with a CNAME? > > > -- > Lea 'LadyBug' Viljanen NameSurfer Ltd > Lea.Viljanen@namesurfer.com WWW-based DNS-tools ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Tue Jan 27 10:17:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA18178 for dns-security-outgoing; Tue, 27 Jan 1998 10:17:35 -0500 (EST) Date: Tue, 27 Jan 1998 10:31:31 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Edward Lewis Cc: dns-security@tis.com Subject: Re: Proposed change to NXT In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk On Wed, 7 Jan 1998, Edward Lewis wrote: > Date: Wed, 7 Jan 1998 14:33:48 -0500 > From: Edward Lewis > > At 1:24 PM -0500 1/7/98, Donald E. Eastlake 3rd wrote: > >On Fri, 2 Jan 1998, Edward Lewis wrote: > >Well, I was talking about nonexistent names, not types. We need to keep > >these straight although a lot of the same considerations apply to both. > > I don't see why there is a difference between non-existent name and > non-existent data at a name - to the "eyes" of the resolver. In either > case, the query is a failure. Is there a difference? Well, from my point of view there are a number of differences. For nonexistent type, you need to find the NXT at the name. For nonexistent name, you need to find the NXT whose name interval brackets the name. For nonexistent type, you return no error code while for nonexistence name you return an error code. And probably other differences that don't occur to me right now. > >... > ... > > >leakage. (I think this problem can be fixed by using root instead of the > >zone in the RDATA and adding a special rule that says leakage of all > >names in root is OK.) > > I'd like to limit the usage of "special rules." There are already too many > artifical boundary cases unnecesarily introduced in the DNS software. The TIS/Olafur proposal has the special case that by using the zone name in the RDATA to indicate that you are not really securing name non-existence, you make it impossible to ever securely deny the existence of a name after the last one in the zone. This seems like a noticeable problem that effects every zone. My suggest to use root in the RDATA to indicate that you are not really securing name non-existence means that you need special case for the root zone to know that you can always authoritatively deny names there. So I think it is trading a special case that causes problems in all zones with a special case that effects only root and doesn't cause a problem I can see since I think that all names in root should be publicly known. It also saves space since root has a nice short name. > >... > ... > > >If the hash is of the FQDN, as I think it should be, then you have to do the > >hashing again for every level. And it's true that no protection is provided > >against an off line guessing attack. But people who want "secret" host names > >should pick longish random ones, just like people who want secret user ids or > >secret passwords. > > My concern is that the limitation of DNS names to 256 (in network format) > bytes makes the "name space" not sparse enough for a brute force guessing > game. I am not sure my concern is founded - assuming a brute for guess > would need to try about 40 characters ( = 26 + 10 + enough to make a round > number), the guesser would have to start from a field of about 40 to the > 250th power names. Of course, expanding the length of the name in the > hashing process makes the space more sparse. I dunno...like I say, this is > just a concern. Given that people consider 128 bit keys (2**128) secure, 40**256 (= 5**2048) would be incredibly strong. Even in hex and using one label, you would have 16**63 (= 2**252). The length of SHA1, 160 bits, is choosen to be secure and, no matter how encoded, as long as the encoding is lossless, you would have 2**160 possibilities, which should be plenty strong. > ... > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis Trusted Information Systems > Phone: +1 301-854-5794 Email: lewis@tis.com > > "Trying is the first step to failure." - Homer Simpson > > Opinions expressed are property of my evil twin, not my employer. Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Wed Jan 28 07:30:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA26483 for dns-security-outgoing; Wed, 28 Jan 1998 07:27:46 -0500 (EST) Message-Id: <199801280844.DAA17752@tapas.nixu.fi> X-Mailer: exmh version 2.0zeta 7/24/97 From: Lea Viljanen To: "Donald E. Eastlake 3rd" cc: Lea Viljanen , dns-security@tis.com Subject: Re: DNSSEC, CNAME & forthcoming CERTs In-reply-to: Your message of "Tue, 27 Jan 1998 10:05:32 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Jan 1998 03:44:31 -0500 Sender: owner-dns-security@ex.tis.com Precedence: bulk > Why do you want this? A CNAME indicates that you are looking up an > alternative / old / wrong name for something and point to the canonical > name. NXT and SIG RR's are allowed at the same name as a CNAME to > secure that CNAME. I'm aware of the purpose of the CNAME and I know DNSSEC does not want to break the idea. But the point being in this case that you might want to bind a KEY (or certificate) to an alias name itself, not the canonical name. The most common example could be www.something.com, where you'd want the KEY to belong to the service alias, not the host implementing the service. I'm thinking of a general public key and certificate distribution service here, not just security of the DNS. Of course there are other alternatives (like creating the alias name as A records), but that's not very pretty. Most of the aliases are created by CNAMEs, I believe. Do we want to change the current practice? > KEY RR's are allowed at a CNAME only for the case > where the zone is delegating authorith to some entity with that name and > that entity decided to CNAME itself to some other name. I don't think this usage restriction is spelled out anywhere in the DNSSEC papers (RFC or the v2 proposal). Or did I just read them sloppily? I believed that the KEY record allowed with a CNAME would have exactly the same meaning as with all other RR's -- i.e you can specify in a KEY record a public key for whatever use. And my logic goes that if we allow a KEY record, we should allow a CERT, since a certificate is bound to a key/owner name and we should be able to store them together. If it is indeed the case, that the KEY RR allowed with a CNAME is not the universal public key record, but restricted in usage to the above mentioned situation, we may have a problem. One of the goals of DNSSEC was to create a key distibution service and if we have two different uses and semantics for a KEY record, this could have an impact on the usability of DNS for this purpose. Besides, I don't think DNS has any other records with different semantics depending on RRs it hangs out with? I know I haven't followed the DNSSEC discussions for very long and I may miss something previously discussed here, but please bear with me and explain. -- Lea 'LadyBug' Viljanen Fact without theory is trivia. Lea.Viljanen@nixu.fi Theory without fact is bullshit. From owner-dns-security Wed Jan 28 10:30:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27947 for dns-security-outgoing; Wed, 28 Jan 1998 10:27:50 -0500 (EST) Message-Id: <199801281513.KAA29719@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: dns-security@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-dnssec-dss-02.txt Date: Wed, 28 Jan 1998 10:13:19 -0500 Sender: owner-dns-security@ex.tis.com Precedence: bulk --NextPart A Revised 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 : DSA KEYs and SIGs in the Domain Name System Author(s) : D. Eastlake Filename : draft-ietf-dnssec-dss-02.txt Pages : 7 Date : 27-Jan-98 A standard method for storing US Government Digital Signature Algorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-dss-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-dss-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-dss-02.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: <19980127111432.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-dss-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-dss-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980127111432.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security Wed Jan 28 10:30:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27959 for dns-security-outgoing; Wed, 28 Jan 1998 10:28:52 -0500 (EST) Message-Id: <199801281513.KAA29738@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: dns-security@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-dnssec-rsa-00.txt Date: Wed, 28 Jan 1998 10:13:23 -0500 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 : RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) Author(s) : D. Eastlake Filename : draft-ietf-dnssec-rsa-00.txt Pages : 6 Date : 27-Jan-98 A standard method for storing RSA keys and and RSA/MD5 based signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. 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-rsa-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-rsa-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-rsa-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: <19980127111750.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-rsa-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-rsa-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980127111750.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security Wed Jan 28 10:30:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27958 for dns-security-outgoing; Wed, 28 Jan 1998 10:28:51 -0500 (EST) Message-Id: <199801281515.KAA29798@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: dns-security@tis.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-dnssec-secext2-03.txt Date: Wed, 28 Jan 1998 10:15:24 -0500 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-03.txt Pages : 51 Date : 27-Jan-98 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 also be provided through non-security aware DNS servers in some cases. The extensions 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 on RFC 2065 from early implementers and potential users. 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-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext2-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-03.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: <19980127092105.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-secext2-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-secext2-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980127092105.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security Wed Jan 28 11:19:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA28419 for dns-security-outgoing; Wed, 28 Jan 1998 11:17:53 -0500 (EST) Date: Wed, 28 Jan 1998 11:32:03 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Lea Viljanen Cc: dns-security@tis.com Subject: Re: DNSSEC, CNAME & forthcoming CERTs In-Reply-To: <199801280844.DAA17752@tapas.nixu.fi> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk Hi Lea, See my comments further down.. On Wed, 28 Jan 1998, Lea Viljanen wrote: > Date: Wed, 28 Jan 1998 03:44:31 -0500 > From: Lea Viljanen > To: "Donald E. Eastlake 3rd" > > > Why do you want this? A CNAME indicates that you are looking up an > > alternative / old / wrong name for something and point to the canonical > > name. NXT and SIG RR's are allowed at the same name as a CNAME to > > secure that CNAME. > > I'm aware of the purpose of the CNAME and I know DNSSEC > does not want to break the idea. > > But the point being in this case that you might want to bind a KEY > (or certificate) to an alias name itself, not the canonical name. > The most common example could be www.something.com, where you'd > want the KEY to belong to the service alias, not the host > implementing the service. I'm thinking of a general public > key and certificate distribution service here, not just security > of the DNS. But as I say, you can put a KEY at the same domain name as a CNAME. And that is really sufficinet since you could always put an indirect KEY there pointing at a certificate elsewhere if you want. (see draft-ietf-dnssec-indirect-key-01.txt) > Of course there are other alternatives (like creating the alias > name as A records), but that's not very pretty. Most of the aliases > are created by CNAMEs, I believe. Do we want to change the > current practice? > > > KEY RR's are allowed at a CNAME only for the case > > where the zone is delegating authority to some entity with that name and > > that entity decided to CNAME itself to some other name. > > I don't think this usage restriction is spelled out anywhere in > the DNSSEC papers (RFC or the v2 proposal). Or did I just > read them sloppily? Sorry I worded my response poorly. I meant that the particular use of KEY RR's that I mentioned was the motivation, and really the only motivation, for allowing KEY RR's at CNAMEs. Of course, once they are allowed there, you can have any kind of KEY RR there and use that KEY RR for whatever purpose you want. > I believed that the KEY record allowed with a CNAME would have > exactly the same meaning as with all other RR's -- i.e you can > specify in a KEY record a public key for whatever use. And my > logic goes that if we allow a KEY record, we should allow a CERT, > since a certificate is bound to a key/owner name and we should be > able to store them together. This does not follow. The KEY RR is necessary for certain circumstances involving DNS security and dynamic update. The CERT RR is not. > If it is indeed the case, that the KEY RR allowed with a CNAME is > not the universal public key record, but restricted in usage to > the above mentioned situation, we may have a problem. No, there is no such restriction. And you can use an indirect KEY to point to a CERT if you want. (Indirect KEYs are ignored for DNS security purposes.) Permitting CERTs at CNAMES would mean yet a further change to DNS implementations. > One of the goals of DNSSEC was to create a key distibution service > and if we have two different uses and semantics for a KEY record, > this could have an impact on the usability of DNS for this purpose. > Besides, I don't think DNS has any other records with different > semantics depending on RRs it hangs out with? > > I know I haven't followed the DNSSEC discussions for very long > and I may miss something previously discussed here, but please > bear with me and explain. > > -- > Lea 'LadyBug' Viljanen Fact without theory is trivia. > Lea.Viljanen@nixu.fi Theory without fact is bullshit. Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-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.privacy.org/ipc From owner-dns-security Thu Jan 29 08:34:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA06966 for dns-security-outgoing; Thu, 29 Jan 1998 08:32:02 -0500 (EST) Message-Id: <199801291327.IAA00685@tapas.nixu.fi> X-Mailer: exmh version 2.0zeta 7/24/97 From: Lea Viljanen To: "Donald E. Eastlake 3rd" cc: dns-security@tis.com Subject: Re: DNSSEC, CNAME & forthcoming CERTs In-reply-to: Your message of "Wed, 28 Jan 1998 11:32:03 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Jan 1998 08:27:34 -0500 Sender: owner-dns-security@ex.tis.com Precedence: bulk > But as I say, you can put a KEY at the same domain name as a CNAME. And > that is really sufficinet since you could always put an indirect KEY > there pointing at a certificate elsewhere if you want. (see > draft-ietf-dnssec-indirect-key-01.txt) What you're saying is, if we want to bind a key and a certificate to an owner name, which is an alias, we put something like (xcuse the syntax): www CNAME foo KEY wwwpubkey KEY INDIRECT/DNS-CERT somename ... foo A 1.2.3.4 KEY foopubkey ... somename CERT whatevercertificate KEY INDIRECT/DNS-KEY www This seems to do the trick, right. Thanks. There is some inconvenience involved, since we need a lot of intermediate placeholder names, but that's a minor nuisance. My other thought with this is that this indirect key is actually quite something other than a key. It's a reference to a key, or even more clashing, a reference to some object other than a key (a CERT). Is it really wise to call it with the same name as a plain KEY? Or is this coupling of function just a trick to prevent opening the CNAME issue even further? How are the implementors supposed to handle this? If I make a query for CERT record for the name www, what's the server to do? Follow the CNAME? Check all the KEYs for possible CERT indirection? And the KEY RR will not be the easiest to parse, since you can't tell by the RR name what type of thingie you'll get. Semantically I would feel more comfortable having this same indirection mechanism attached to both the KEY and CERT RR's. I.e. if I want to refer to an URL giving me a certificate, I'd have a CERT RR with indirection fields instead of something used to refer to a key. However, that would mean allowing the CERTs with a CNAME, sigh. BTW, the indirect-key-01.txt seems to have a critical typo in section 2.1: the target type numbering goes 0,1,2,2,3... P.S. This indirect key stuff reminds me of a quote I read yesterday: "Every problem in computer science can be solved with one more level of indirection". - David Wheeler -- Lea 'LadyBug' Viljanen NameSurfer Ltd Lea.Viljanen@namesurfer.com WWW-based DNS-tools