Re: [DNSOP] Comments regarding the NSEC5

[Jan Včelák <[e-mail]>]

Hello Florian,

On 11.3.2015 12:01, Florian Weimer wrote:
> do you plan to submit this to an IETF working group, or as an individual
> submission?

We plan to submit the draft 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.

It dependes whether you see zone enumeration as a problem. NSEC5 is
designed as an alternative to NSEC/NSEC3, not a replacement.

If you consider the data in your zone public, use NSEC. If you need
Opt-Out, use NSEC3. If you don't want attackers to enumerate your zone,
use NSEC5 (or disable DNSSEC [sic]). And you are right, NSEC5 creates
additional performance capacity requirement. Everything comes at a price.

> 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?

> 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.

OK. You are right. It is underspecified.

In addition, there is an error in the quoted text. Therefore both of
your interpretations are incorrect. I will fix that.

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)))

> 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.

A few sentences are in 7.1. (NSEC5PROOF RDATA Wire Format): "Owner Name
Hash is a variable sized sequence of binary octets encoding the NSEC5
proof corresponding to the owner name."

It's the NSEC5 proof. Again, in your notation:
FDH(Wire-Encode(owner name), privkey))

I agree that the description is insufficient. We will fix that.

> 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.

You are right. This is wrong. I will fix that.

> 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.

Good point.

> 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.

NSEC5 relies on deterministic signature scheme for NSEC5 proofs. We
can't really use non-deterministic scheme, because we need exactly one
valid signature for a domain name and a key.

If the signature scheme allowed to issue two different valid signatures
for one input, the slave servers could cheat on the client. Because that
would render different NSEC5 hashes and thus different positions in the
NSEC5 chain.

Why is the FDH difficult to implement? Take a look at Appendix A. in our
draft.

I also wrote a reference implementation for FDH in OpenSSL and
GnuTLS/Nettle. You can take a look at it and review the code (nobody did
it yet): https://gitlab.labs.nic.cz/knot/nsec5-crypto

> 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.

Not really. The chain is build from NSEC5 hashes. And the client cannot
compute the NSEC5 hash without having the NSEC5 proof. And the NSEC5
proof cannot be computed without the private key.

Thank you a lot for your remarks! I will process them soon.

Best regards,

Jan