On Mar 23, 2015, at 10:15 AM, Jan Včelák <jan.vce...@nic.cz> 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. - The statement about NSEC3 "offline dictionary attacks are still possible and have been demonstrated" doesn't take into account trivial changes that an operator can choose to take if they are really concerned about offline dictionary enumeration (with the trade-off being zone size). - The draft does not discuss the increased CPU resources needed on every authoritative server to respond to non-existent queries relative to simply serving NSEC or NSEC3 directly. - Section 2 says "The zones signed according to this specification MUST use only these [NSEC5-based] algorithm identifiers, thus NSEC5-unaware resolvers will treat the zone as insecure" without acknowledging that such a tradeoff is unneeded if the operator uses NSEC3 obfuscation instead. - Section 10, "Resolver Considerations", doesn't mention that the NSEC5 private keys must be securely distributed out-of-band when the NSEC5KEY RR is updated, nor that the private key must be atomically updated when the NSEC5KEY is updated. - There is no discussion of how many queries an attacker needs to send to enumerate a zone with NSEC5. In the real world, it is pretty easy to send queries for each string in a dictionary, making NSEC5 just as vulnerable as NSEC3, yet at a much higher operational cost. Overall, this seems like a novel idea that comes with a huge operational overhead and no actual demand. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
