Hi Jan, do you plan to submit this to an IETF working group, or as an individual submission?
It's not clear if the security goals make sense. What do zone operators gain if zone enumeration attacks are moved from offline to online, other than a need to provision additional server capacity? It's not that they can block resolution requests from large resolvers if a part of their client population participates in aggressive enumeration. Section 4 says, “NSEC5 hash is an SHA-256 hash function as specified in [RFC6234].” Are you sure that's right? In any case, most references to “NSEC5 hash” are underspecified. For example, in section 9.1, “The owner name of the NSEC5 RR is the NSEC5 hash of the original owner name encoded in Base32hex without padding, prepended as a single label to the zone name”, could be read in various different ways. It seems that Base32hex(SHA-256(Wire-Encode(owner name))) is meant, but it could also be read as SHA-256(Base32hex(owner name)) or something like that. There does not seem to be anything in the draft that describes how the RDATA of the NSEC5PROOF is computed. I think the intent is that it contains SHA-256(Wire-Encode(NSEC5 owner name)), and the validation is performed using a separate RRSIG record, signed with the NSEC5KEY public key. However, section 9.2 does not mention that the NSEC5PROOF record is accompanied by an RRSIG RRset. The rollover mechanism in section 9.3 does not work reliably. The old public key must be kept around until the TTL on the old NSEC5 and NSEC5PROOF RRs have expired (after the authoritative servers stopped serving them). The old public key cannot be removed immediately. It must be possible to re-fetch it in case a caching resolver expired it for some reason. In Section 11.1, “at least one of the keys MUST validate”: This MUST is misleading because the section is about validator behavior, it needs to be lower case because this section cannot establish constraints on validator input. There needs to be some discussion regarding the TTL on the NSEC5PROOF record, the validator should not accept arbitrary values there. These days, online signatures should really use a non-deterministic signature scheme. The deterministic FDH algorithm is very difficult to implement correctly. But it is not actually referenced in the draft, there are no protocol elements that use FDH values. As specified in the draft, the NSEC5 protocol still exposes the chain of SHA-256 hashes of owner names. It does not offer better protection against offline dictionary attacks than NSEC3. Florian -- Florian Weimer / Red Hat Product Security _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
