On 3/23/15, 14:08, "Paul Hoffman" <[email protected]> wrote:
>On Mar 23, 2015, at 10:15 AM, Jan Včelák <[email protected]> wrote: >> I just submitted an updated NSEC5 draft into the data tracker. The most >> significant change is fixing the NSEC5 key rollover mechanism; the rest >> are just typo fixes and small clarifications in terminology. > >This proposal continues to have fundamental problems that are not >documented in the draft. Missing in 14.5 - remember that for NSEC3, we had to create new dnssec-algorithm numbers (well, one) for RSA-SHA-1 (algorithms 5 and 7) to "ensure" that the validator was new enough to understand NSE3 (or treat the zone as unsigned). Regardless of the other features of NSEC5, if there's no way to signal that a zone only uses NSEC5 then the proposal will never get deployed. It doesn't mean a new set of algorithm numbers (RSA-SHA1, RSA-SHA256, that elliptic curve thing, GOST, etc.), although it might, but it could be some other new, novel means. Yes, a new round of algorithm numbers without a new round of algorithms isn't very palatable. (Kind of puts a damper on innovating in this space, huh?) >Overall, this seems like a novel idea that comes with a huge operational >overhead and no actual demand. I agree. More interesting to me than stopping enumeration (I'm a NSEC'r anyway) is 1) coming up with a smaller response payload in negative responses (NSEC3 needs up to 3 sets, NSEC needs up to 2 sets) and 2) coming up with a more explainable response. (You try understanding what a NSEC3 proof is stating.)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
