On Mar 23, 2015, at 6:23 PM, Jan Včelák <jan.vce...@nic.cz> wrote: >> 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?
Sure. When signing the zone, instead of creating one NSEC3 record for a gap, you create 10 or 100 with random intervals between the two hashes. That way an attacker is more likely to get results that will not match dictionary entries. > 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. NSEC5 has significant operational consequences. Deferring the description of them until later doesn't help the WG evaluate whether or not this proposal is worth considering. >> - 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? No. As a zone administrator, you decide whether to sign your zone with NSEC or NSEC3. You are prosing to make that decision "NSEC or NSEC3 or NSEC5", but without acknowledging tradeoffs. >> - 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"? Sorry, my fault. I should have said: Section 9.4, Secondary Servers, 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. Instead, it only says "This document does not define mechanism to distribute NSEC5 private keys". > 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. This protocol is an operational change to the way that DNSSEC is provided. Having a critical piece of that operation be out of scope for your proposal is inappropriate. > 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. That part is clear: what isn't clear is the importance of getting that on all secondaries. >> - 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.) Yes, exactly. > >> 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. People who don't want to disclose the content of a zone don't serve the zone. That is not the operational tradeoff that NSEC3 addresses. > Thank you for the feedback. I hope the above helps you improve the proposal or, possibly, abandon it. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
