On 15/06/2015 22:35, Paul Hoffman wrote:
"NSEC3": whether not NSEC3 is "quite different" from NSEC depends on your context.
Functionally, in the narrow sense of "allows verifiable denial of existence", they are identical. I
think it would be clearer to focus on their functional similarities, and point out the additional features of
NSEC3 (opt-out and making zone enumeration harder), observing that any particular signed zone must use
exactly one of these, not both (so, they are alternatives, and one of them is required).
Disagree. Even in the "allows verifiable denial of existence", they are quite different
in that the processing needed is very different. The "fundamental similarities" are only
in what is achieve, not in the way of achieving it.
Perhaps we could agree on some text that confirms that they are functionally similar,
whilst having quite different approaches to achieving that functionality? That seems like
it would be better than declaring them to be "quite different".
The current text says:
NSEC3:
: The NSEC3 resource record is quite different than the NSEC resource record.
Like the NSEC record, the NSEC3 record also provides authenticated denial of
existence; however,
NSEC3 records mitigates against zone enumeration and support Opt-Out.
NSEC3 resource records are defined in {{RFC5155}}.
I think the second sentence says what you want, and the first sentence is
factually correct in the that the records themselves really are different.
I dislike the current text especially "is quite different than the NSEC
resource record"
NSEC3: An alternative to NSEC. The NSEC3 RR allows verifiable denial of
existence. However, is allows the zone signer to "Opt-out" and not
create an NSEC3 RR at insecure (no DS) delegations. This has the
advantage of allowing the zone size to scale gracefully with the
increase in signed delegations. This is especially useful for operators
of large delegation centric zones. In addition, NSEC3 uses hashed owner
names in order to make zone enumeration approximately as hard as it
would be in an unsigned zone.
This make me think that the document should define owner name and
possibly the NSEC3PARAM RR.
regards
John
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
