Subject: [dnsext] Authenticated denial of existence...

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Nov 2013 22:30:04 -0500

Is this on anyone's radar?   What are your thoughts about it?

https://datatracker.ietf.org/doc/draft-gieben-auth-denial-of-existence-dns/

---

From: [email-masked]
Date: Wed, 20 Nov 2013 05:51:58 +0000

yes.  did you read/follow the NSEC4 discussions a few years back?
 this is a fine piece of work that clearly lays out the path of NSEC work
 and the ramifications for wildcards (5.3 & 5.4)...

 overall a needed addition to the DNS documentation library.  

 why do you ask?

/bill

On Tue, Nov 19, 2013 at 10:30:04PM -0500, Ted Lemon wrote:
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Nov 2013 01:27:56 -0500

> why do you ask?

Conflict review.  My impression is the same, and it can be argued that since DNSEXT no longer exists, there can't be a conflict.  But I wanted to bounce it off the list before making that claim, since in principle the work could be done in INTAREA, but would probably be done by people who read this mailing list.

Thanks!

---

From: [email-masked]
Date: Wed, 20 Nov 2013 06:52:21 +0000

dnsext does exist, its just not meeting.  it (in a perfect world) would be shut down.
 if the "conflict" is DNSEXT (not currently accepting new work, but still existing) and ISE,
 then there is really no other route than ISE, since the WG refuses to take the work on and
 there is no other existent venue.

 e.g. a conflict, but self-imposed by the lack of will to actually shut down a zombie WG.

 IMHO of course.

/bill

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Nov 2013 01:54:54 -0500

> e.g. a conflict, but self-imposed by the lack of will to actually shut down a zombie WG.

Au contraire, the working group was shut down a while back.   The mailing list remains.

---

From: joel jaeggli <[email-masked]>
Date: Tue, 19 Nov 2013 22:56:47 -0800

>  there is no other existent venue.

DNSEXT is concluded. the mailing list continues.

---

From: "Jiankang Yao" <[email-masked]>
Date: Wed, 20 Nov 2013 14:59:40 +0800

good writing of this draft.

I am interested the following text in section 3:
"   2.  The DNS packet header is not signed.  This means that a "status:
       NXDOMAIN" can not be trusted.  In fact the entire header may be
       forged, including the AD bit (AD stands for Authentic Data, see
       RFC 3655 [RFC3655]), which may give some food for thought;
"
so if the resolver is attacked, such as hacking the "status" field or the whole header, what will happen?

Jiankang Yao

From: Ted Lemon
Date: 2013-11-20 11:30
To: Group 
Subject: [dnsext] Authenticated denial of existence...
Is this on anyone's radar?   What are your thoughts about it?

---

From: Miek Gieben <[email-masked]>
Date: Wed, 20 Nov 2013 07:53:59 +0000

[ Quoting <[email-masked]> in "Re: [dnsext] Authenticated denial o..." ]
> so if the resolver is attacked, such as hacking the "status" field or the whole header, what will happen?

A good resolver should check the complete message and then header so see if they
match. Of course this only works if the message contains signatures. 

Should we add something along these lines to the draft. Currently it is an
"exercise for the reader", which I kinda like.

Regards,
Miek

---

From: Tony Finch <[email-masked]>
Date: Wed, 20 Nov 2013 12:12:19 +0000

> https://datatracker.ietf.org/doc/draft-gieben-auth-denial-of-existence-dns/

A really nice and helpful document.

A suggestion:

It should discuss RFC 4470 Minimally Covering NSEC Records, and the
related idea of NSEC3 "white lies" implemented by Dan Kaminsky's
Phreebird. (I can't immediately find a good description of how the latter
works.) Both these require on-demand synthesizing and signing of negative
responses, whereas the mechanisms that Miek's draft currently covers are
all designed for serving from a pre-signed zone file without requiring
online private keys.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Miek Gieben <[email-masked]>
Date: Wed, 20 Nov 2013 13:05:46 +0000

[ Quoting <[email-masked]> in "Re: [dnsext] Authenticated denial o..." ]
> A really nice and helpful document.

Thanks.

> all designed for serving from a pre-signed zone file without requiring

I'm not sure how far in the review process we actually are with this draft,
and adding text about this is a considerable effort. However I think it is
valuable to have text on this in this draft too.

Regards,

-- 
   Miek Gieben

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 20 Nov 2013 14:40:11 +0100

I would like to add some more text about minimally covering records, but
I would not like to disturb the current flow of the document. In other
words, I suggest it to be either a short notice, or to appear as an
appendix.

Best regards,
  Matthijs

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Nov 2013 10:22:04 -0500

> "exercise for the reader", which I kinda like.

It's an ISE document.   Do it the way you want.   If you see a suggestion here that you think is worth following, please go ahead, but you are under no obligation to do so.   A conflict review simply checks to make sure that there isn't somewhere that this work ought to be happening within the IETF.

---

From: Miek Gieben <[email-masked]>
Date: Wed, 20 Nov 2013 15:38:19 +0000

[ Quoting <[email-masked]> in "Re: [dnsext] Authenticated denial o..." ]
> It's an ISE document.   Do it the way you want.   If you see a suggestion here that you think is worth following, please go ahead, but you are under no obligation to do so.   A conflict review simp…

Ack. Thanks for the clarification.

-- 
   Miek Gieben

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 20 Nov 2013 12:53:22 -0500

> A really nice and helpful document.

Agreed.  Really well put-together.  I do like the previously mentioned
ideas of including a bit about RFC 4470 and a few short words on
alternatives to managing the nsec3 hash space (like Kaminsky's).
Appendix is fine to not disrupt the flow, and it probably doesn't
really need more than a paragraph or so for each.

Section 3[.0] should probably elaborate on this:

   When you are querying a name server for a record that actually
   exists, a man-in-the-middle may replay that generic denial record
   and it would be impossible to tell whether the response was genuine
   or spoofed.

especially when later on 3.2 says this:

   Therefore, the RRSIG's RDATA include a validity period (not visible
   in the zone above), so that an attacker cannot replay this NXDOMAIN
   response for "c.example.org" forever.

which could easily leave the reader wondering, "so why doesn't having
a validity period on a generic denial record adequately address this?"

I realize the answer is obvious to us, but it isn't obvious in the
document, which is meant to be accessible by people outside the
security sphere.

Maybe this subtle would work?  I'm not entirely sure how much it does
help, but does start to point in the right direction.

   When you are querying a name server for any record that actually
   exists, a man-in-the-middle could replay that generic denial record
   that is not limited in its scope and it would be impossible to tell
   whether the response was genuine or spoofed.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Nov 2013 07:50:53 +1100

You may want to have some discussion about the pointlessness of
NSEC3 in highly structured zones like ip6.arpa and in-addr.arpa.
These can be walked even with NSEC3 due to their structure.

You may want to point out that a NSEC proves the existance of all
empty non-terminals between the two names in it hence contains the
closest provable encloser.

There is a bias that NSEC3 is better than NSEC.  They are just
different.  NSEC3 is actually worse for the typical trivial zone
as it doesn't help with zone walking as you can guess the names and
adds pointless computational load on both authoritative servers and
validators.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Miek Gieben <[email-masked]>
Date: Wed, 20 Nov 2013 21:37:40 +0000

[ Quoting <[email-masked]> in "Re: [dnsext] Authenticated denial o..." ]
> closest provable encloser.

Ack and ack. These would indeed be good things to add.

> adds pointless computational load on both authoritative servers and

I agree with your assertions, but I hope to keep the draft purely
technical.

Grtz, Miek

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 21 Nov 2013 08:31:23 +0100

Hi,

> really need more than a paragraph or so for each.

Thanks. Miek and I are going to cover the topic.

>    whether the response was genuine or spoofed.

I agree. Thank you for providing text.

Best regards,
  Matthijs

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 22 Nov 2013 10:43:19 +0100

As a result of writing down text relating RFC 4470 in
draft-gieben-auth-denial-of-existence-dns, I come to the following
observation:

RFC 4470 sets requirements for the next owner name in the generated NSEC
record. Specifically, the next owner name is lexically before the actual
next existing name in the zone. The next owner name must be lexically
after the QNAME. The span may not cover any existing names.

Main point: I cannot find requirements for the owner name. In other
words, that may be an existing name.

But the RFC explicitly says:

   The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
   bits set and SHOULD NOT have any other bits set.

That is only true if the owner name does not exist. So either this
requirement should be relaxed, or there should be an additional
requirement that the generated NSEC owner name may not exist.

(By the way, I think the requirement should be relaxed, because a
minimally covering NSEC record may also be used in a NODATA response)

Best regards,
  Matthijs

---

From: Tony Finch <[email-masked]>
Date: Fri, 22 Nov 2013 14:06:11 +0000

> words, that may be an existing name.

There are two cases: "instantiated names" which are names that exist in
the zone, in which case the owner name of the NSEC record matches the
owner name of the other records (para. 2 of sect. 3); and proofs of
nonexistence generated on-demand (para. 3 of sect. 3):

   Whenever an NSEC record is needed to prove the non-existence of a
   name, a new NSEC record is dynamically produced and signed.  The new
   NSEC record has an owner name lexically before the QNAME but
   lexically following any existing name and a "next name" lexically
   following the QNAME but before any existing name.

>    bits set and SHOULD NOT have any other bits set.

That is the first sentence of para. 4 of sect. 3 which refers to the
on-demand NSEC records described in the previous paragraph.

> minimally covering NSEC record may also be used in a NODATA response)

For NODATA responses you use the NSEC record of an instantiated name,
which can be minimally covering as described in para. 2 of sect. 3.

Tony.

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 22 Nov 2013 16:52:20 +0100

> on-demand NSEC records described in the previous paragraph.

It is not clear to me that this sentence only refers to the on-demand
NSEC records. Especially because the sentence talks about "generated
NSEC record's type bitmap" and in para. 1 of sect 3. it is mentioned
that for instantiated names, NSEC records can still be generated and
signed in advance.

But yes, it makes sense that the rule only applies to non-existent names.

Best regards,
  Matthijs

---

From: Tony Finch <[email-masked]>
Date: Fri, 22 Nov 2013 15:59:16 +0000

Matthijs Mekking <[email-masked]> wrote:

> NSEC records.

I think the other sentence in the same paragraph makes it clear that the
whole paragraph is about NXDOMAIN responses:

   The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
   bits set and SHOULD NOT have any other bits set.  This relaxes the
   requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
   names that did not exist before the zone was signed.

Tony.

---

From: Miek Gieben <[email-masked]>
Date: Mon, 25 Nov 2013 14:05:08 +0000

[ Quoting <[email-masked]> in "Re: [dnsext] Authenticated denial o..." ]

Hi,

Matthijs and I added an extra appendix to cover on-line signing and
made some tweaks to the rest of the text.

See:
http://www.ietf.org/id/draft-gieben-auth-denial-of-existence-dns-04.txt
Diff:
http://www.ietf.org/rfcdiff?url2=draft-gieben-auth-denial-of-existence-dns-04

Regards,
Miek Gieben

---

From: Tony Finch <[email-masked]>
Date: Mon, 25 Nov 2013 15:43:56 +0000

> made some tweaks to the rest of the text.

Looks good.

A point I just noticed in section 3 which I think could do with
elaborating:

      Given all these troubles, why didn't the designers of DNSSEC go
      for the (easy) route and allowed for on-line signing?  Well, at
      that time (pre 2000), on-line signing was not feasible with the
      then current hardware.  Keep in mind that the larger servers get
      between 2000 and 6000 queries per second (qps), with peaks up to
      20,000 qps or more.  Scaling signature generation to these kind of
      levels is always a challenge.  Another issue was (and is) key
      management, for on-line signing to work you need access to the
      private key(s).  This is considered a security risk.

I think it is worth saying that online signing makes it difficult to have
third party secondary authoritative servers, since they would need a copy
of the private ZSK. With normal DNSSEC, even with a dynamically updated
zone, the private keys do not need to be on a publicly accessible machine.

Tony.

---

From: Jelte Jansen <[email-masked]>
Date: Mon, 25 Nov 2013 16:55:47 +0100

> zone, the private keys do not need to be on a publicly accessible machine.

now that you quote it like that, I think that using 'allowed' in that
first line is misleading; it's not so much that the protocol doesn't
allow on-line signing, the requirement was that it didn't have to rely
on it. Also, IIRC the preferred term was on-the-fly rather than on-line.

Need to re-read doc :)

Jelte

---

From: Tony Finch <[email-masked]>
Date: Mon, 25 Nov 2013 15:59:10 +0000

> on it. Also, IIRC the preferred term was on-the-fly rather than on-line.

Good points. What's the best opposite for on-the-fly? Pre-signed?

Tony.

---

From: Jelte Jansen <[email-masked]>
Date: Mon, 25 Nov 2013 17:04:39 +0100

> Good points. What's the best opposite for on-the-fly? Pre-signed?

I guess so, or maybe pre-generated in a slightly wider context

Jelte

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 26 Nov 2013 08:14:01 +0100

> Good points. What's the best opposite for on-the-fly? Pre-signed?

I don't want to be nitpicking on words, but RFC 4470 has "on-line
signing" in its title. And then off-line seems to me the obvious opposite.

I do prefer "requirement of not relying on it" better than "allowed"

Best regards,
  Matthijs

---

From: Tony Finch <[email-masked]>
Date: Tue, 26 Nov 2013 10:56:40 +0000

> signing" in its title. And then off-line seems to me the obvious opposite.

I would really like to avoid that because too many people think DNSSEC
zone signing has to be a batch operation. It would be nice to have
a phrase that also covers incremental dynamic signing.

Tony.

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 28 Nov 2013 11:14:28 +0100

Hi,

FYI, Miek and I posted a new version of this document which diff is very
small compared to -04.

Best regards,
  Matthijs

Changelog:
   1.  Minor fixes and adjustments.

URL:

http://www.ietf.org/internet-drafts/draft-gieben-auth-denial-of-existence-dns-05.txt

Diff:

http://www.ietf.org/rfcdiff?url2=draft-gieben-auth-denial-of-existence-dns-05

Abstract:
   Authenticated denial of existence allows a resolver to validate that
   a certain domain name does not exist.  It is also used to signal that
   a domain name exists, but does not have the specific RR type you were
   asking for.  When returning a negative DNSSEC response, a name server
   usually includes up to two NSEC records.  With NSEC3 this amount is
   three.

   This document provides additional background commentary and some
   context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide
   authenticated denial of existence responses.