Subject: Re: Opt-in

From: David Blacka <[email-masked]>
Date: Tue, 16 Aug 2005 15:08:26 -0400

On Aug 16, 2005, at 10:24 AM, Ben Laurie wrote:

> I've been reviewing the security considersations of http:// 
> www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt- 
> in-07.txt. It seems to me that the statement:
>
>    In particular, this means that a malicious entity may be able to
>    insert or delete records with unsigned names.  These records are
>    normally NS records, but this also includes signed wildcard
>    expansions (while the wildcard record itself is signed, its  
> expanded
>    name is an unsigned name).
>
> This seems to me to be incorrect, since a denial of a domain must  
> include a denial for the matching wildcard. Similarly, the wildcard  
> being signed means that "insertion" isn't possible if there's a  
> wildcard present, since all records would exist anyway.

What this is trying to say is that an attacker (presumably a MitM)  
can undetectably insert an unsigned delegation that blocks a wildcard  
expansion.  And conversely, the attacker could undetectably replace a  
normal unsigned delegation with a wildcard expansion (if there was a  
wildcard present, that is).

So, in one sense this paragraph is a little misleading because the  
attacker isn't "inserting" a wildcard expansion, the attacker is  
*replacing* an unsigned delegation with the wildcard expansion.

Also note that section 4.1.3 of the draft relaxes the requirement to  
provide the denial for the matching wildcard in the rcode=3  
(NameError) case.  While the logic in that section is mine, I have to  
admit that I'm not entirely confident that its conclusion is the  
right one.

--
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

--
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: Rob Austein <[email-masked]>
Date: Tue, 16 Aug 2005 15:46:25 -0400

> admit that I'm not entirely confident that its conclusion is the  

No doubt I'm missing something obvious, but could we solve the
wildcard interaction problem simply by stating that the opt-foo bit
can't apply to a range containing a wildcard?  That is, can we just
state that wildcards, if present, must be signed, and that an opt-foo
NSEC3 means by definition that there is no wildcard in that range?

I haven't yet made up my mind on the resurrection of opt-foo, but if
we do keep it I'm pretty sure that I'd prefer the above approach to
losing the "not covered by a wildcard" part of the Name Error proof.

---

From: David Blacka <[email-masked]>
Date: Tue, 16 Aug 2005 16:18:25 -0400

> NSEC3 means by definition that there is no wildcard in that range?

It already says that.  (Discounting wildcard NS records ;)

> losing the "not covered by a wildcard" part of the Name Error proof.

This is not because the wildcard RR set is not signed or not in the  
NSEC{3} chain -- it is.  This is because you cannot quite prove  
rcode=3 when the covering NSEC is opt-in, so why bother *also*  
proving that there is no wildcard (which, I repeat, you can do)?

Maybe *I'm* missing something obvious, but what is this "wildcard  
interaction problem", really?

And, honestly, section 4.1.3 could be changed to require that rcode=3  
responses include the NSEC record that proves no wildcard exists  
without hurting anything.  I'm just not sure that it buys you  
anything, so why should the validator have to do the work?  OTOH, I  
think I can be easily convinced to make this change.

---

From: Rob Austein <[email-masked]>
Date: Tue, 16 Aug 2005 17:12:57 -0400

At Tue, 16 Aug 2005 16:18:25 -0400, David Blacka wrote:
> > ... That is, can we just state that wildcards, if present, must be
> > signed, and that an opt-foo NSEC3 means by definition that there
> > is no wildcard in that range?
> 

4.1.1 says SHOULD, not MUST.

> interaction problem", really?

It's a consistancy thing, I dunno how much it matters.  As I think I
understand it, the opt-foo model is signed records rather than signed
zones.  One way of looking at this is that it's the same model as
DNSSECbis but certain portions of a zone are flagged as dropping out,
leaving a signed subset of the zone.  So a "no such name in zone"
proof turns into a "no such signed name in zone" proof, which (to my
mind, anyway) includes "no signed covering wildcard in zone."

> think I can be easily convinced to make this change.

I'm not sure it buys anything either, and will admit that there's a
case to be made here either way.  On the one hand, I think that
including the NSEC/NSEC3 is more consistant (and DNSSEC in general is
already umpty-three levels deep in baroque fixes to our previous
cleverness, opt-foo brings it to umpty-four, so retaining what little
consistancy remains in this house of cards seems good to me...); on
the other hand, omitting the NSEC/NSEC3 saves some bandwidth.  Dunno.

In any case: upon further analysis (or, if you prefer, upon swapping
in foggy memories), the answer to my original question is that my
proposal above doesn't suffice, because it doesn't handle an unsigned
positive answer that masks a signed wildcard.  Only fix I see for that
would be changing SHOULD in 4.1.1 to MUST.

---

From: David Blacka <[email-masked]>
Date: Tue, 16 Aug 2005 19:56:56 -0400

> 4.1.1 says SHOULD, not MUST.

4.1.1 has some squishiness to it because it is talking about how the 
tools behave, which is an area that, at least at the time, folks were 
reluctant to say MUST.

But signing the wildcard really is a MUST: see section 4.2.1.

> mind, anyway) includes "no signed covering wildcard in zone."

And it does.

> the other hand, omitting the NSEC/NSEC3 saves some bandwidth.  Dunno.

I agree.  When this language was added, there was some concern that the 
negative wildcard proof was "hard", so being able to avoid it was nice. 
  Now we know better, so, I agree, it could go either way and be OK.

> would be changing SHOULD in 4.1.1 to MUST.

After reading 4.2.1, do you still think 4.1.1's SHOULDs should change to 
MUSTs?

-- 
David Blacka    <[email-masked]>
Sr. Engineer    Verisign Applied Research

---

From: Roy Arends <[email-masked]>
Date: Thu, 18 Aug 2005 12:48:09 +0200 (CEST)

> losing the "not covered by a wildcard" part of the Name Error proof.

IMHO the wildcard/opt-in interaction is as follows:

Opt-in is basically an NSEC that covers an unsigned span where one or
more unsigned delegations appear.

A signed wildcard RRset is exactly that, a record with an ownername
starting with an asterisk, signed entirely. It will never appear as such
in an opt-in span.

What a MITM is able to do wrt the unsigned span is to replace an existing
unsigned delegation with a synthesised wildcard and vice versa. The
synthesised wildcard is not signed after it was synthesised, the
accompanying signature appearing there is the signature over the original
wildcard.

As to impact and remedy, lets keep in mind a similar attack with DNSSEC
without opt-in:

Since we assume a mitm and an unsigned delegation, a MITM is able to
rewrite the unsigned delegation to a virtual server under its control, and
answer the original query from there with whatever it desires (including
that what would essentially be a synthesised wildcard in the previous
scenario). Ofcourse, the MITM could also send an NXDOMAIN/NODATA back
claiming the original queried name and/or type does not exist. Since this
attack gives the MITM more freedom as to what to respond to the original
requestor, i find the impact of opt-in/wildcard interaction benign.

In short, with or without opt-in, since it is an unsigned delegation, all
bets are off, regardless whether opt-in is used.

The remedy is to have a secure delegation to a signed child.

Roy

---

From: Ben Laurie <[email-masked]>
Date: Thu, 18 Aug 2005 15:46:18 +0100

David Blacka wrote:
>> www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt- in-07.txt. 
>> It seems to me that the statement:
>>
>>    expansions (while the wildcard record itself is signed, its  expanded
> What this is trying to say is that an attacker (presumably a MitM)  can 
> undetectably insert an unsigned delegation that blocks a wildcard  

Ah, I see.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Rob Austein <[email-masked]>
Date: Thu, 18 Aug 2005 13:01:15 -0400

> But signing the wildcard really is a MUST: see section 4.2.1.
...
> After reading 4.2.1, do you still think 4.1.1's SHOULDs should change to 

I think it would be advisable to change them to MUST, yes.  Current
spec inverts the robustness principle: sender is permitted to signal
semantics that receiver is not allowed to accept.

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 23 Aug 2005 14:19:38 -0400 (EDT)

> It already says that.  (Discounting wildcard NS records ;)

I'm confused by this, and I'm worried that David and Rob are talking
around each other here.

It sounded to me like Rob was saying: "there can be no wildcard
expansions within an opt'ed-out span" -- basically, wildcards don't
work in opt'ed out spans.

My understanding of the current spec is that wildcard RR's, because
they're not delegations (or, at least, we hope they're not
delegations) must be signed.  And are applicable everywhere, no matter
the opt-foo state of the span or zone.  But the draft changes the
proof logic since names can be spoofed in/out of an opt'ed-out span.

Perhaps I'm just confused, but I think I'd be less confused by talking
about what resolvers/validators do, rather than what zone content is
allowed.  "If you get an unsigned wildcard...."

-- Sam