Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
Thanks Evan and Andrew fot translating my thoughts into better prose. Evan, you captures my meaning. Olafur On 20/02/2010 4:31 PM, Evan Hunt wrote: I think Olafur's point is a good one, but I'm unhappy with the prose. Some suggested changes below. Same here. Nits: There are to mechanisms to provide authenticated proof of s/to/two/ Each mechanism includes a list of all the RRTYPEs present at the s/includes/stores/ The clear text version has its one RRtype for negative answer, Clear text one uses NSEC record and the obfuscated one used NSEC3. I didn't know how to rephrase that, because if I understand it I think what I understand is wrong (but that's obviously not the case, so probably I don't understand it). I think he meant "each version has its own RRtype". Suggested change: "Each mechanism uses a specific RRTYPE to store information about the RRTYPEs present at the name: the clear-text mechanism uses NSEC, and the obfuscated-data mechanism uses NSEC3." It may also be worth mentioning that the two mechanisms are usually referred to by the names of their corresponding RR types. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
> I think Olafur's point is a good one, but I'm unhappy with the prose. > Some suggested changes below. Same here. Nits: > There are to mechanisms to provide authenticated proof of s/to/two/ > Each mechanism includes a list of all the RRTYPEs present at the s/includes/stores/ > > The clear text version has its one RRtype for negative answer, Clear > > text one uses NSEC record and the obfuscated one used NSEC3. > > I didn't know how to rephrase that, because if I understand it I think > what I understand is wrong (but that's obviously not the case, so > probably I don't understand it). I think he meant "each version has its own RRtype". Suggested change: "Each mechanism uses a specific RRTYPE to store information about the RRTYPEs present at the name: the clear-text mechanism uses NSEC, and the obfuscated-data mechanism uses NSEC3." It may also be worth mentioning that the two mechanisms are usually referred to by the names of their corresponding RR types. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
I think Olafur's point is a good one, but I'm unhappy with the prose. Some suggested changes below. On Sat, Feb 20, 2010 at 08:37:16AM -0500, Olafur Gudmundsson wrote: > There are two meachanisms to provide authenticated proof of > exsitance/non-existance in DNSSEC. A clear text one and a obfuscated > one. There are to mechanisms to provide authenticated proof of non-existence in DNSSEC: a clear text one and an obfuscated-data one. Each mechanism includes a list of all the RRTYPEs present at the name. Each mechanism includes only the name for which the zone is authoritative (that is, glue in the zone is omitted). The clear text mechanism is implemented using a sorted linked list of names in the zone. The obfuscated-data mechanism first hashes the names using a one-way hash function, and then sorts the resulting (hashed) strings. > The clear text version has its one RRtype for negative answer, Clear > text one uses NSEC record and the obfuscated one used NSEC3. I didn't know how to rephrase that, because if I understand it I think what I understand is wrong (but that's obviously not the case, so probably I don't understand it). A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Sat, 20 Feb 2010, Alex Bligh wrote: There are two meachanisms to provide authenticated proof of exsitance/non-existance in DNSSEC. I don't believe either provides proof of existence (apart from existence of the NSECx record). If you can proof one, you can also proof the other :) I think they both only provide proof of non-existence (and in the case of NSEC3 opt out, not even that). That I agree with. NSEC3 plus OPT-OUT does not give a full authenticated proof of non-existance. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
--On 20 February 2010 08:37:16 -0500 Olafur Gudmundsson wrote: There are two meachanisms to provide authenticated proof of exsitance/non-existance in DNSSEC. I don't believe either provides proof of existence (apart from existence of the NSECx record). I think they both only provide proof of non-existence (and in the case of NSEC3 opt out, not even that). -- Alex Bligh ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
5. Next Record type There are currently two types of next records that are provide authenticated denial of existence of DNS data in a zone. I have a problem with this presentation. There are two mechanishm to provide proof of non-existance, each has a RR type associated with it. The text of section 5 as written places the RRtype as the main focus rather than the technique used. One of the issues I have been running into is that people assume that NSEC3 is a replacement of NSEC because of the naming of the records i.e. NSEC3 is 3'rd version of NSEC ; For this reason I would advoacte that this section be retuned to talk about the mechanishms first then cover the on the wire details and records. o The NSEC [4] record builds a linked list of sorted RRlabels with their record types in the zone. o The NSEC3 [24] record builds a similar linked list, but uses hashes instead of the RRLabels. My draft rewrite of 5. There are two meachanisms to provide authenticated proof of exsitance/non-existance in DNSSEC. A clear text one and a obfuscated one. Both mechanishms for each name include a list of all the RRtypes present at the name. Both mechanishms only include the names the zone is authoratitve, i.e. glue names present in the zone are omiited. * The clear text one is implemented via a sorted link list of names in the zone. * The obufscated first hashes the names via one-way hash function and then sorts the resulting strings. The clear text version has its one RRtype for negative answer, Clear text one uses NSEC record and the obfuscated one used NSEC3. If you agree with this change in focus is benefital I will be happy to help rewrite the remainder of the section. Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
