Hi Paul, > 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).
Please, can you clarify which trivial solution in particular do you mean? There is a paper "Stretching NSEC3 to the Limit: Efficient Zone Enumeration Attacks on NSEC3 Variants" by Sharon Goldberg et al, which covers some of the trivial solutions and explains why it won't work: http://www.cs.bu.edu/~goldbe/papers/nsec3attacks.pdf > - 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. Yes, that's right. We would like to cover this in the "Performance Considerations" section, which is not ready at the moment. > - 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. I'm not sure if I understand this correctly. If the zone uses NSEC5 for authenticated denial ("zones signed according to this specification"), then it must use only NSEC5 capable algorithms ("these algorithm identifiers"). Otherwise an NSEC5-unaware resolver would treat the denying responses from the server as bogus. Does it make sense? > - 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. Does it fit the "Resolver Considerations"? Yes, we don't define any mechanism to distribute the private keys to other authoritative servers. I think this is out of the scope of the draft. We can provide more details about the private key exchange during the NSEC5 key rollover. The key itself is bound to one NSEC5 chain - so during the rollover, when the NSEC5 chain is replaced, the new private key is started to be used. > - 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. To enumerate the zone, you will need approximately the same amount of queries you will need to enumerate a plain unsigned zone. (Assuming that the server responds to ANY. And ignoring wildcards, which are easily recognizable in DNSSEC.) > Overall, this seems like a novel idea that comes with a huge operational > overhead and no actual demand. Yes, it comes at a price. People who don't want to disclose content of a zone may already use online signing and the overhead is huge as well. NSEC5 just makes it possible to have the zone signing key offline. Thank you for the feedback. Cheers, Jan _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
