Subject: [DNSOP] Comments regarding the NSEC5

From: Florian Weimer <[email-masked]>
Date: Wed, 11 Mar 2015 12:01:44 +0100

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

---

From: Florian Weimer <[email-masked]>
Date: Wed, 11 Mar 2015 17:30:16 +0100

On 03/11/2015 05:19 PM, Jan Včelák wrote:

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

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

---

From: Jan Včelák <[email-masked]>
Date: Wed, 11 Mar 2015 17:39:35 +0100

> resolvers.  NSEC5 takes away that option.  Do the existing enumerators

I really can't tell. I don't know.

> your comment,s it's clearly *not* SHA-256, contrary to what I quoted above.

NSEC5 proof is the FDH of domain name.
NSEC5 hash is SHA-256 of NSEC5 proof.

I will clarify that.

> is the SHA-256 hash skipped?

Yes, the SHA-256(...) is the NSEC5 hash. The input is NSEC5 proof.

Jan

---

From: Jan Včelák <[email-masked]>
Date: Wed, 11 Mar 2015 17:19:04 +0100

Hello Florian,

> do you plan to submit this to an IETF working group, or as an individual

We plan to submit the draft as an individual submission.

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

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

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

> must be possible to re-fetch it in case a caching resolver expired it

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

> the NSEC5PROOF record, the validator should not accept arbitrary values

Good point.

> 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

> 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

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 11 Mar 2015 09:52:55 -0700

> On Mar 11, 2015, at 9:39 AM, Jan Včelák <[email-masked]> wrote:
> 

Why not just do something simpler?  The only thing NSEC5 really differs in a way that counts is not in the NSEC record but really just the DNSKEY handling, having a separate key used for signing the NSEC* records.

So why define NSEC5 at all.

Instead, just specify a separate flag for the DNSKEY record, "NSEC-only", sign the NSEC3 dynamically, bada bing, bada boom, done!

For old resolvers, they just ignore the flag and treat it like any other DNSKEY record, and since the valid names are signed with the other key, while the NSEC* are signed with this key, it works just fine.

For upgraded resolvers, they follow the convention and only will accept RRSIGs for NSEC/NSEC3 with that DNSKEY record.

And then on the authority side, you just dynamically generate and sign the NSEC3 record that says H(name)-1 to H(name)+1 has no valid record and sign that with the NSEC-only key.

This way, you gain the protection against enumeration and the limited damage on key compromise property when validated by upgraded resolvers, and you still get the protection against enumeration when the resolver isn't upgraded, and you don't need to upgrade the resolver in order for this to be deployed.

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Mar 2015 10:02:31 -0700

> I really can't tell. I don't know.

Proposal: until there is evidence that there is a community that needs the features of NSEC5 that cannot be easily replicated in NSEC3, this WG does not consider a protocol change that would require every resolver to be updated.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 Mar 2015 14:18:52 -0400 (EDT)

> This way, you gain the protection against enumeration and the limited damage on key compromise property when validated by upgraded resolvers, and you still get the protection against enumeration wh…

I agree. Guess we would find out how much of a DDOS this dynamic signing
will be though :P

Paul

---

From: Jan Včelák <[email-masked]>
Date: Thu, 12 Mar 2015 11:15:06 +0100

On Wednesday, March 11, 2015 09:52:55 AM Nicholas Weaver wrote:
> Why not just do something simpler?  The only thing NSEC5 really differs in a
> way that counts is not in the NSEC record but really just the DNSKEY
> handling, having a separate key used for signing the NSEC* records.
> 
> Instead, just specify a separate flag for the DNSKEY record, "NSEC-only",
> sign the NSEC3 dynamically, bada bing, bada boom, done!

This would not work. Anyone holding the NSEC-only private key could fake 
denying answers for the zone. So if your zone is slaved by a less-trusted 
party, they could still manipulate your zone. This is not possible with NSEC5.

Jan

---

From: Jan Včelák <[email-masked]>
Date: Thu, 12 Mar 2015 11:26:01 +0100

On Wednesday, March 11, 2015 10:02:31 AM Paul Hoffman wrote:
> Proposal: until there is evidence that there is a community that needs the
> features of NSEC5 that cannot be easily replicated in NSEC3, this WG does
> not consider a protocol change that would require every resolver to be
> updated.

I think that's reasonable.

On the other hand, I would still appreciate some feedback on the proposed 
NSEC/NSEC3 -> NSEC5 transition mechanism, which is currently quite painful and 
I consider it the weakest point of the proposal. I believe that finding an 
alternative would make NSEC5 acceptable for more people.

Currently, the transition is done the same way as in NSEC -> NSEC3, using the 
DNSKEY algorithm aliases. That time it was easy - only two aliases were 
allocated for RSA and DSA with SHA-1. Right now, we have at least four 
suitable algorithms: RSA with SHA-{256,512} and ECDSA P-{256,384}.

Jan

---

From: Florian Weimer <[email-masked]>
Date: Thu, 12 Mar 2015 11:31:37 +0100

> party, they could still manipulate your zone. This is not possible with NSEC5.

They can still respond with SERVFAIL instead of supplying a signed
answer, achieving roughly the same result.

A better argument would be support for opt out, where signatures from
the online key could introduce unauthorized positive answers.  It's
still not a very strong argument, admittedly.  The DNS software itself
is likely signed by a key which is kept online (more or less).  Online
keys are less threatening than they used to be, and we aren't even
talking about long-term keys baked into software, but short/medium-term
keys which are easily replaced.

And does anyone actually use opt out with NSEC3?

---

From: Jan Včelák <[email-masked]>
Date: Thu, 12 Mar 2015 11:36:20 +0100

On Thursday, March 12, 2015 11:31:37 AM Florian Weimer wrote:
> >> Why not just do something simpler?  The only thing NSEC5 really differs
> >> in a way that counts is not in the NSEC record but really just the
> >> DNSKEY handling, having a separate key used for signing the NSEC*
> >> records.
> >> 

Yes, .com for example. My impression was that Opt-Out was the selling point of 
NSEC3, not the domain name hashing.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 12 Mar 2015 12:39:17 +0100

> NSEC3, not the domain name hashing.

Okay.  Are they interested in switching to NSEC5?

---

From: Ondřej Surý <[email-masked]>
Date: Sun, 15 Mar 2015 17:28:38 +0100 (CET)

JFTR I don't think the target audience is TLDs, but I have heard a several times speaking to me that they won't implement DNSSEC because of enumeration (citing djb's paper on NSEC3 offline enumeration).  Those folks are the target audience for the cryptographically proven anti-enumeration solution.

Cheers,
Ondrej

--
 Ondřej Surý -- Chief Science Officer
 --------------------------------------------
 CZ.NIC, z.s.p.o.    --     Laboratoře CZ.NIC
 Milesovska 5, 130 00 Praha 3, Czech Republic
 mailto:[email-masked]    https://nic.cz/
 --------------------------------------------

----- Original Message -----
> From: "Florian Weimer" <[email-masked]>
> To: "Jan Včelák" <[email-masked]>
> Cc: [email-masked], "Nicholas Weaver" <[email-masked]>
> Sent: Thursday, March 12, 2015 12:39:17 PM
> Subject: Re: [DNSOP] Comments regarding the NSEC5

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Jan Včelák <[email-masked]>
Date: Mon, 16 Mar 2015 10:56:13 +0100

On Thursday, March 12, 2015 12:39:17 PM Florian Weimer wrote:
> > Yes, .com for example. My impression was that Opt-Out was the selling
> > point of NSEC3, not the domain name hashing.
> 

I was trying to say that TLDs use NSEC3 because of Opt-Out. This seems to be 
true, based on the information Edward sent in the "Using NSEC3 for opt-out" 
thread.

The target audience for NSEC5 are people, who care about the zone enumeration. 
They could be using Minimally Covering NSEC Records or NSEC3 White Lies at the 
moment. Both of these mechanisms already require on-line signing and private 
zone signing keys on all authoritative servers. NSEC5 just removes the 
necessity to have keys on the servers.

Jan

---

From: Jan Včelák <[email-masked]>
Date: Mon, 23 Mar 2015 16:15:02 +0100

Hi,

I just submitted an updated NSEC5 draft into the data tracker. The most
significant change is fixing the NSEC5 key rollover mechanism; the rest
are just typo fixes and small clarifications in terminology.

http://datatracker.ietf.org/doc/draft-vcelak-nsec5/

Also, I will have a 10 minute talk about the draft on the Security Area
Open Meeting on Thursday. You are welcome to come.

Regards,

Jan

---

From: Bob Harold <[email-masked]>
Date: Mon, 23 Mar 2015 13:26:55 -0400

The completed sections of draft looks good to me, with one exception.

I think we might need to allow for more than one NSEC5 key and chain,
during a transition.  Otherwise it might be impossible to later create a
reasonable transition process.  This might require us to tag the NSEC5
records with an id, so that the chains and matching keys can be
distinguished.  Better to do this now than to try to retrofit later.

A few minor corrections or suggestions:

section 1.1 "Rationale"
"As side-effect, however, the NSEC chain existence allows for the
   enumeration of the zone's contents by querying for names immediately
   individual RRs in the chain;"
-- Seems to be missing a word between "immediately" and "individual"

section 1.1 "Rationale"
"The NSEC5 is not intended to replace NSEC or NSEC3.  It is designed
   as an alternative mechanisms for authenticated denial of existence."
-- I think "mechanisms" should be "mechanism" (singular, not plural).

section 4 "NSEC5 Algorithms"
"The algorithms used for NSEC5 authenticated denial are independent on
   the algorithms used for DNSSEC signing."
-- Change "independent on" to "independent of" ?

-- 
Bob Harold
hostmaster, UMnet, ITcom
Information and Technology Services (ITS)
[email-masked]
734-647-6524 desk

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Mar 2015 14:08:30 -0500

> are just typo fixes and small clarifications in terminology.

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

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

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

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

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

Overall, this seems like a novel idea that comes with a huge operational overhead and no actual demand.

--Paul Hoffman

---

From: Paul Vixie <[email-masked]>
Date: Mon, 23 Mar 2015 12:20:11 -0700

> Paul Hoffman <mailto:[email-masked]>
> Monday, March 23, 2015 12:08 PM
>
> ...
> Overall, this seems like a novel idea that comes with a huge
> operational overhead and no actual demand.

+1.

-- 
Paul Vixie

---

From: Edward Lewis <[email-masked]>
Date: Mon, 23 Mar 2015 20:32:49 +0000

>This proposal continues to have fundamental problems that are not

Missing in 14.5 - remember that for NSEC3, we had to create new
dnssec-algorithm numbers (well, one) for RSA-SHA-1 (algorithms 5 and 7) to
"ensure" that the validator was new enough to understand NSE3 (or treat
the zone as unsigned).

Regardless of the other features of NSEC5, if there's no way to signal
that a zone only uses NSEC5 then the proposal will never get deployed.  It
doesn't mean a new set of algorithm numbers (RSA-SHA1, RSA-SHA256, that
elliptic curve thing, GOST, etc.), although it might, but it could be some
other new, novel means.

Yes, a new round of algorithm numbers without a new round of algorithms
isn't very palatable.

(Kind of puts a damper on innovating in this space, huh?)

>overhead and no actual demand.

I agree.  More interesting to me than stopping enumeration (I'm a NSEC'r
anyway) is 1) coming up with a smaller response payload in negative
responses (NSEC3 needs up to 3 sets, NSEC needs up to 2 sets) and 2)
coming up with a more explainable response.  (You try understanding what a
NSEC3 proof is stating.)

---

From: Jan Včelák <[email-masked]>
Date: Mon, 23 Mar 2015 23:38:29 +0100

> distinguished.  Better to do this now than to try to retrofit later.

Please, can you clarify which transition process do you mean?

> A few minor corrections or suggestions:

Thank you. These will be fixed in the next version.

---

From: Jan Včelák <[email-masked]>
Date: Tue, 24 Mar 2015 00:23:51 +0100

Hi Paul,

> - 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 real…

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 ack…

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 atomi…

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 N…

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Mar 2015 07:57:09 -0500

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

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

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

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

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

> key is started to be used.

That part is clear: what isn't clear is the importance of getting that on all secondaries.

> the server responds to ANY. And ignoring wildcards, which are easily

Yes, exactly.

> 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

---

From: Jan Včelák <[email-masked]>
Date: Tue, 24 Mar 2015 15:56:46 +0100

> 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 th…

This is described in the mentioned paper as "NSEC3 with dummy records".
It's not a good solution - the cost for the name server is higher than
the cost for the attacker.

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

Sure. We just wanted some early feedback.

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

OK.

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

I disagree. This can be implementation specific. From the same reason we
don't define format for NSEC5 private keys. This is a general problem of
DNS provisioning. I'm persuaded that defining some provisioning protocol
within NSEC5 is a bad idea.

> That part is clear: what isn't clear is the importance of getting that on all secondaries.

OK.

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

That's more a philosophical question. Depends if you think that the data
in the zone are public. If you are an attacker, the first think you will
probably do is to determine attack vectors on a target system. And the
DNS zone may provide a lot of useful information about the system
architecture.

> I hope the above helps you improve the proposal or, possibly, abandon it.

Both is possible. :-)

Jan

---

From: Matthäus Wander <[email-masked]>
Date: Tue, 24 Mar 2015 16:41:09 +0100

> 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 th…

This slows down the online hash collection but not the offline
dictionary enumeration. The attacker will have to send 10 or 100 times
as many queries (which of course the server administrator pays by having
to send 10 or 100 times as many negative responses).

In the offline attack, the performance is dominated by the effort for
hashing the input dictionary. Whether you're matching the output against
1000 or 100000 hash values has little influence on the total performance.

Regards,
Matt

---

From: Warren Kumari <[email-masked]>
Date: Tue, 24 Mar 2015 13:11:37 -0500

>>> http://www.cs.bu.edu/~goldbe/papers/nsec3attacks.pdf

Yes, this was presented at (IIRC) DNS-OARC in Los Angeles. While the
paper is correct, my view of the response was "shrug", and "this is
not a problem worth spending resources to solve". While some zone
operators want to minimize zone enumeration, it's not really viewed as
a huge issue. This is like buying a triple hardened bank vault door to
protect a slice of cake.

>>> NSEC5 just makes it possible to have the zone signing key offline.

Sure, you might not want folk to just download your zone and walk off
with it, but ... If you put something in a zone, and expect that to
remain secret, you are in for a bad day.

The contents of zones quickly becomes visible, what with passive DNS,
DITL, people who connect in place X, and then reopen their laptop in
place Y, etc.

> in the zone are public.

It is -- or, at least, it soon becomes so.

> If you are an attacker, the first think you will

Perhaps not naming your NEC Point of Sale terminal as
nec-cashregister-running-nOS3-14.example.com would be a better idea
than assuming that this will remain "secret". If you really want,
there is split dns, etc, but if you stick things in a publicly
accessible zone, you should expect it will become public....

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Mar 2015 13:20:40 -0500

> On Mar 24, 2015, at 10:41 AM, Matthäus Wander <[email-masked]> wrote:
> 

Completely true. However, the existence of NSEC5 is predicated on the idea that a zone admin cares so much about zone enumeration that they are willing to risk having their zone appear unsigned to resolvers that do not implement NSEC5. If that zone admin finds that cost too high, but has lots of CPU available during signings, they should know that they have that alternative.

Again: a proposal for an operational change to DNSSEC needs to be explicit about the tradeoffs, particularly when one of the options is "you will be considered unsigned by some resolvers when you implement this". The current draft is not have this.

--Paul Hoffman

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 24 Mar 2015 11:35:20 -0700

> On Mar 24, 2015, at 11:11 AM, Warren Kumari <[email-masked]> wrote:

And if you REALLY want this, TODAY, get a HSM (optional), program it to ONLY sign NSEC3 records, and just dynamically sign (and cache) NSEC3 records for your NXDOMAINs.

You use the HSM to protect the key if you are paranoid, and you get "no enumeration" records.  By caching the responses, you prevent a DOS from preventing you from serving up common NXDOMAIN records, and the DOS only affects the NXDOMAIN side anyway: you can probably get the same results in most cases by serving up an NXDOMAIN without an NSEC3 RRSET, as the resolver will go "this doesn't validate" and give a servfail anyway.

---

From: Jan Včelák <[email-masked]>
Date: Tue, 24 Mar 2015 20:07:54 +0100

> a huge issue. This is like buying a triple hardened bank vault door to

Is the cake delicious?

> DITL, people who connect in place X, and then reopen their laptop in

I know and I completely agree.

On the other hand, there are efforts (DPRIVE) to make this data
collection more difficult.

> accessible zone, you should expect it will become public....

The reason why I started to write the draft was to find out, how the
theory is applicable in the real-world DNS. I really like the idea of
NSEC5. It's a proper way of preventing zone enumeration, while having
the zone signing key offline.

I know that the changes to the protocol are invasive and that the
performance degradation is significant. I want that to be documented. If
we quantify the benefits and trade-offs, the zone operators can decide
if NSEC5 is worthy.

Jan

---

From: Bob Harold <[email-masked]>
Date: Tue, 24 Mar 2015 15:08:23 -0400

> Please, can you clarify which transition process do you mean?

Transitioning from one NSEC5 key to another.  I think the process would
need to be:
- add new NSEC5 key RR, but not used yet.  Also add new private to all
authoritative servers.
- wait for new key to reach everywhere (propagation + ttl)
- change all  NSEC5 records in the zone.
- wait for new records to reach everywhere
- remove old NSEC5 key record.  Also remove old private key from all
authoritative servers.
But for the servers and public to know which key to use, there will need to
be some id that matches NSEC5 records to the matching NSEC5 key.  That
requires changing the format of the NSEC5 records, so it cannot be done
later.

---

From: Jan Včelák <[email-masked]>
Date: Tue, 24 Mar 2015 20:27:06 +0100

On 24.3.2015 20:08, Bob Harold wrote:
> 
> On Mon, Mar 23, 2015 at 6:38 PM, Jan Včelák wrote:
> 

I don't think we need to wait till updated NSEC5 records get everywhere.
Also with NSEC3, the two servers can answer from different NSEC3 chains
as far as the chains are signed correctly.

The server must switch to a new private key at the moment, when it gets
an updated NSEC5 chains and drops the old one. Right, that's one of the
things which should be clarified.

> But for the servers and public to know which key to use, there will need
> to be some id that matches NSEC5 records to the matching NSEC5 key. 
> That requires changing the format of the NSEC5 records, so it cannot be
> done later.

You should never get a zone with NSEC5 records mixed from two different
chains. The change of the NSEC5 chain must be atomic. That is required
by the draft.

What is missing in the draft is, how to determine a correct NSEC5
private key to use to compute the NSEC5 proofs. What comes to my mind is
that when the zone is loaded (or the chain is updated), the server could
just compute the NSEC5 hash of the zone apex and determine, which key is
in use. That could work even without the id.

But this is definitely a good point. I will think about it.

Thank you.

Jan

---

From: Jan Včelák <[email-masked]>
Date: Tue, 24 Mar 2015 20:32:53 +0100

> Again: a proposal for an operational change to DNSSEC needs to be explicit about the tradeoffs, particularly when one of the options is "you will be considered unsigned by some resolvers when you i…

That's right.

---

From: Bob Harold <[email-masked]>
Date: Tue, 24 Mar 2015 16:04:15 -0400

On Tue, Mar 24, 2015 at 3:27 PM, Jan Včelák <[email-masked]> wrote:

> That's simpler, and removes the need for the id.
(That's why you are designing this and not me.)  Then the process becomes:
- add new private key to all authoritative servers.
- change NSEC5 key and all NSEC5 records in the master zone
- wait for zone to reach all slaves
- each time the NSEC5 key record changes, the servers test to see which
private key it uses.
- remove old private key from all authoritative servers.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 24 Mar 2015 16:25:06 -0400 (EDT)

> collection more difficult.

Not quite. DPRIVE is about anonymity of the querier, not anonymity of
the zone data. As per Charter:

 	The primary focus of this Working Group is to develop mechanisms that
 	provide confidentiality between DNS Clients and Iterative Resolvers,
 	but it may also later consider mechanisms that provide confidentiality
 	between Iterative Resolvers and Authoritative Servers, or provide
 	end-to-end confidentiality of DNS transactions.

Paul

---

From: Jan Včelák <[email-masked]>
Date: Tue, 24 Mar 2015 23:02:08 +0100

>     end-to-end confidentiality of DNS transactions.

OK, right. Anyway, the trend is obvious.

---

From: Jan Včelák <[email-masked]>
Date: Wed, 25 Mar 2015 16:51:14 +0100

> - remove old private key from all authoritative servers.

I agree. I will update the draft to clarify the replacement of the
private key during the rollover process.

Thank you, Bob.

Jan