On 03/11/2015 05:19 PM, Jan Včelák wrote: >> 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. > > It dependes whether you see zone enumeration as a problem.
If I really want to enumerate a zone, I will just send my dictionary as queries, possibly through open resolvers. People are reckless like that. At least with NSEC3, polite attackers can do some of the processing off-line, without punishing authoritative servers or resolvers. NSEC5 takes away that option. Do the existing enumerators care? Who knows. >> Section 4 says, “NSEC5 hash is an SHA-256 hash function as specified in >> [RFC6234].” Are you sure that's right? > > You mean the reference to the RFC? Yes, I think it's right. Or am I > missing something? I'm guessing, but “NSEC5 hash” is probably what involves FDH. Based on your comment,s it's clearly *not* SHA-256, contrary to what I quoted above. > We deal with NSEC5 proofs and NSEC5 hashes (see the Terminology > section). The NSEC5 proof is the FDH (can be comptuted only by the > holder of the NSEC5 private key); the NSEC5 hash is an SHA-256 hash of > the NSEC5 proof (everyone can compute it, if they know the NSEC5 proof). > > So in your notation, an NSEC5 RR owner name should be: > Base32hex(SHA-256(FDH(Wire-Encode(owner name), privkey))) And the inner part (without the Base32 encoding) is the NSEC5 hash? Or is the SHA-256 hash skipped? You really need to make this explicit. > I agree that the description is insufficient. We will fix that. Thanks. -- Florian Weimer / Red Hat Product Security _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
