Subject: DNSSECbis question (authenticated denial)

From: Roy Badami <[email-masked]>
Date: Wed, 9 Mar 2005 11:57:16 +0000

More specifically, the case I'm thinking of is:

.com implements DNSSECbis, and a.com is securely delegated.

I query for b.a.com, but a man in the middle returns a name error with
the following proof:

a.com. NSEC aa.com. NS DS NSEC RRSIG
a.com. RRSIG NSEC ...

Clearly the NSEC RR indicates I've been spoofed; the presence of NS
records at a.com indicates that there is a delegation there.

However it seems to me that a naive implementation of a resolver
according to -protocol section 5.4 might accept this proof, since it
both proves that b.a.com does not exist in the zone, and that no
relevent wildcard exists in the zone, which is all that -protocol
instructs resolvers to verify.

I could just be confused though ;-)

	-roy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Roy Arends <[email-masked]>
Date: Thu, 10 Mar 2005 03:40:02 +0100 (CET)

> I could just be confused though ;-)

You're not confused. You have found a major oversight in the dnssec-bis
-protocol draft.

We'll need to add text in section 5.4 and possible other sections that a
security aware resolver MUST check the absence of the NS bit and the
DNAME bit.

Thanks,

Roy

---

From: Roy Badami <[email-masked]>
Date: Thu, 10 Mar 2005 10:38:11 +0000

Roy> You're not confused. You have found a major oversight in the
    Roy> dnssec-bis -protocol draft.

Oh well...

Anyway, here is why I was thinking about this...

With NSEC, the proof that there is no delegation ends up being kind of
implicit, at least for the nameserver.  A MITM would necessarily
reveal the presence of the delegation when proving that there is no
wildcard under it, so the nameserver doesn't need to do anything
special to prove the lack of delegation in its responses.

However this only works because the place where the wildcard would
fall is always adjacent to its parent label in canonical order (ie if
a.com is a delegation, then the NSEC record proving there is no
wildcard *.a.com will always have a.com as its owner name).

However once you hash the entire owner name, this ceases to be the
case -- any number of other names could hash between a.com and
*.a.com.

So an NSEC3 nameserver will have to explicitly prove the non-existence
of an NS record at each label up to the closest non-empty encloser by
returning the appropriate NSEC3 record of each parent label.

In the case of opt-in, you still want to do this, to prove there is no
secure delegation above the query name, in order to prevent a MITM
attack similar to the one in my previous mail.

    -roy

---

From: Roy Badami <[email-masked]>
Date: Thu, 10 Mar 2005 10:42:45 +0000

Roy> So an NSEC3 nameserver will have to explicitly prove the
    Roy> non-existence of an NS record at each label up to the closest
    Roy> non-empty encloser by returning the appropriate NSEC3 record
    Roy> of each parent label.

Oops, that dosn't make sense.  Let me try again...

An NSEC3 nameserver will have to explictly prove the non-existence of
an NS record at each label up to and including the closest encloser,
by returning appropriate covering NSEC3 records.

   -roy

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 10 Mar 2005 09:11:57 -0600

>security aware resolver MUST check the absence of the NS bit and the

Roy B, this is a good catch!

It is very tempting to fix this in AUTH48. Actually thre are a few other
things that could be addressed in AUTH48 too, such as the "protocol
violation" that white lies cause. But I am very hesitative to touch the
documents.

When Sam Weiler came up with a few nits a week or two ago, I asked him 
if he could live with documenting them in an "DNSSEC Implementation 
Notes I-D". My motivation for this approach is that the class of nits 
that are found now are typically the things that are fixed when a 
document is advanced from proposed to draft standard.  It would not 
surprise me if we were to find more places where we have to clarify 
behaviour or even stretch normative language when we get more experience 
with implementing and running the protocol.  The issue that Roy B. 
brought up is not a "protocol-bug"  but text that is worthy to be 
highlighted in an implementation note.

I propose _not_ to touch the DNSSECbis document set (which are at the
top of the RFC queue so the timescale on which they will apear is going
to be weeks instead of months) but document this issue  in the I-D that
Weiler  will be editing (see
http://www.ietf.org/internet-drafts/draft-weiler-dnsext-dnssec-bis-updates-00.txt). 

The idea is to keep this document around for a year or two, untill we
have seen multiple implementations operated in the field, and then use
the document, together with interoperability reports, to move DNSSECbis
from proposed to draft.

Please speak up if you think this is not a good approach and/or the
'implementation notes' document should not become a working group document.

--Olaf
  DNSEXT Co-Chair

---

From: Ben Laurie <[email-masked]>
Date: Thu, 10 Mar 2005 14:40:17 +0000

> returning the appropriate NSEC3 record of each parent label.

No, because there should be no records below the NS record in the parent 
zone, so if there is an NS, it will be at the closest encloser. The same 
argument applies to NSEC, as far as I can see.

> attack similar to the one in my previous mail.

I'm less sure about the opt-in situation. Thinking about it.

---

From: Roy Badami <[email-masked]>
Date: Thu, 10 Mar 2005 23:05:06 +0000

Ben> No, because there should be no records below the NS record in
    Ben> the parent zone, so if there is an NS, it will be at the
    Ben> closest encloser. The same argument applies to NSEC, as far
    Ben> as I can see.

Indeed there shouldn't.  So presenting an NSEC record that proves that
such a name exists proves that the delegation doesn't.  DNSSECbis
non-existence proofs implicitly rely on this.

When I query for a.b.c.d.e and get the response:

     _.b.c.d.e. NSEC aa.b.c.d.e. A

this implicitly proves to me that no delegation exists between the
name I queried for and the zone apex, because if it did then the NSEC
owner name and target name wouldn't be in-zone.

When I query for a.c.d.e.e and get the response:

     b.c.d.e. NSEC aa.b.c.d.e. A

this explicitly proves to me that b.c.d.e is not a delegations point
(no NS record) and implictly proves that there is no delegation
between b.c.d.e and the zone apex, for the same reason.

So with DNSSECbis the set of NSEC records you construct to prove that
there is no relevent wildcard that could have matched also happen to
prove that there is no delegation for which you should have received a
referal.

Since the NSEC3 records are ordered by hash, not original owner name
(I think) it seems to me that you don't get this proof for free, and
have to explictly provide covering NSEC3 records for all the places a
delegation could have existed, to prove that it doesn't.

But I haven't thought about this deeply, and could be mistaken...

    -roy

---

From: Ben Laurie <[email-masked]>
Date: Thu, 10 Mar 2005 22:13:06 +0000

> But I haven't thought about this deeply, and could be mistaken...

I believe that since NSEC3 also shows the record at the closest 
encloser, the same check works.

---

From: Roy Badami <[email-masked]>
Date: Thu, 10 Mar 2005 23:22:58 +0000

Olaf> The issue that Roy B.  brought up is not a "protocol-bug"
    Olaf> but text that is worthy to be highlighted in an
    Olaf> implementation note.

Hmm, I think it's borderline, but it feels like a protocol bug to me.
At the moment a resolver could fail to check that the NS and DNAME
bits are clear, and still be conformant with -protocol.  Which means
that the protocol specified in that document has a security flaw.
Sure, it may be obvious to you guys who designed the protocol that you
always _meant_ for the resolver to check that, so it's just an
editorial bug to you.

But that's not the way it seems to someone coming to the documents
without the history...

That said, I understand the desire not to mess with the documents at
this late stage, and there are other aspects of the non-existence and
wildcard proofs that took me a long time to figure out just from
-protocol (and I'm still not sure I've got them right) so maybe a new
document is pragmatically the right place to document these issues.
(I'll post about the bits I find unclear shortly, though it will be a
couple of days before I have time...)

    Olaf> The idea is to keep this document around for a year or two,
    Olaf> untill we have seen multiple implementations operated in the
    Olaf> field, and then use the document, together with
    Olaf> interoperability reports, to move DNSSECbis from proposed to
    Olaf> draft.

I would suggest that, depending on the number and significance of
issues, an initial version should be advanced as an informational RFC
_much_ sooner than that, maybe a early as a matter of months after
publication of DNSSECbis as RFC....

	-roy

---

From: Roy Badami <[email-masked]>
Date: Thu, 10 Mar 2005 23:28:20 +0000

Ben> I believe that since NSEC3 also shows the record at the
    Ben> closest encloser, the same check works.

But what about names between the query name and the closest encloser?

Don't you need to not only prove that a wildcard doesn't exist at each
of those names, but also that a delegation doesn't exist at each of
those names?  The same NSEC3 record won't generally cover the wildcard
and the NS record.

    -roy

---

From: Ben Laurie <[email-masked]>
Date: Fri, 11 Mar 2005 17:05:02 +0000

> But what about names between the query name and the closest encloser?

They don't exist.

> of those names,

No, because if a wildcard existed at one of them, then that name would 
exist, and so the closest encloser would be that name instead.

> but also that a delegation doesn't exist at each of

I claim it will.