Subject: Re: Advance request for opt-in and experiments

From: Edward Lewis <[email-masked]>
Date: Thu, 6 Jul 2006 12:56:23 -0400

At 17:51 +0200 7/6/06, Roy Arends wrote:
>Sam Weiler wrote on 07/06/2006 03:26:32 PM:
>
>>  The wildcard section (4.1.3 in opt-in-08) appears to have disappeared
>>  in opt-in-09, and I'm not recalling the WG's discussion of that.
>>  Would someone kindly refer me to it?
>
>That section was wrong and redundant. Wrong because that specific section
>dealt with full opt-in (not delegation only opt-in). Redundant since the
>issues surrounding opt-in and wildcards is covered in section 8 as well.
>Section 4 discussses Protocol Additions, while section 4.1.3 in opt-in-08
>explained a security consideration.

Part of Sam's question is 'where is the WG's discussion of the 
change' as this is a WG document.

>The original reason for section 4.1.3 was that it seemed that the use of
>opt-in and wildcards are a special corner case. It is _not_ a special
>corner case.

I do recall long discussions about the interaction of wild cards and 
opt-in the last time significant progress was made on this issue.

If opt-in restricts opt-ed out domains to being delegation points and 
we are currently avoiding any word on wild card NS records (in the 
wcard draft, RFC "rfc-editor queue *still*") I think there is a 
consideration to cover.

Let's say I have *.example TXT in the zone.  This would generate 
names anywhere there is nothing else, potentially outside/inside an 
opt-in/out span.  I suppose that we can write this off by saying that 
the proof show the real source to be *.example.  Fine, but, what 
about a replay of the opt-in NSEC covering the query name?  This 
dilemma ought to be recognized.

We can't opt-out a wildcard.  Because only NS's can be opted-out and 
wildcards can't reliably own NS's.

>An opt-in span may contain unsigned delegations (i.e. onwernames that only
>own NS records, not any other records). Section 8 (security
>considerations) explain the security issues surrounding unsigned names. In
>particular, this means that a malicious entity may be able to insert or
>delete records with unsigned names.  These records are normally NS

'normally'?

>records, but this also includes signed wildcard expansions (while the
>wildcard record itself is signed, its expanded name is an unsigned name),
>which can be undetectably removed or used to replace an existing unsigned
>delegation.
>
>(last two sentences are quoted from section 8).

That's the dilemma.  Wildcards and opt-in have never really mixed.  I 
think that's significant to get it's own section.

BTW, I'm fine with such a bump in an experimental RFC.  Not saying 
anything about standards eventualities, but it's okay to play.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Soccer/Futbol. IPv6.  Both have lots of 1's and 0's and have a hard time
catching on in North America.

That tournament in Germany.  What's all the fuss?  (Get it? "fuss?")

--
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: David Blacka <[email-masked]>
Date: Thu, 6 Jul 2006 13:47:25 -0400

> change' as this is a WG document.

There wasn't a recent one.

> opt-in/out span.  I suppose that we can write this off by saying  
> that the proof show the real source to be *.example.  Fine, but,  
> what about a replay of the opt-in NSEC covering the query name?   
> This dilemma ought to be recognized.

This is basically what removing section 4.1.3 was about.  4.1.3 tried  
to justify a change in the proof structure of a positive wildcard  
response when the qname was covered by an opt-in NSEC.  The logic  
wasn't solid, so I removed it.

> That's the dilemma.  Wildcards and opt-in have never really mixed.   
> I think that's significant to get it's own section.

You keep saying that, and I continue to not understand what you are  
talking about.  If there is an unaddressed problem with wildcards in  
the current draft, please bring it up.

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

---

From: Edward Lewis <[email-masked]>
Date: Thu, 6 Jul 2006 15:16:53 -0400

At 13:47 -0400 7/6/06, David Blacka wrote:

>You keep saying that, and I continue to not understand what you are talking
>about.  If there is an unaddressed problem with wildcards in the current
>draft, please bring it up.

http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01745.html

---

From: Roy Arends <[email-masked]>
Date: Thu, 6 Jul 2006 22:18:44 +0200

> >You keep saying that, and I continue to not understand what you are 
talking
> http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01745.html

Dave's question was, 'If there is an unaddressed problem with wildcards in 
the current draft, please bring it up'.

This is not an unaddressed problem since 
http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01747.html is 
reflected in the security considerations.

Roy

---

From: David Blacka <[email-masked]>
Date: Thu, 6 Jul 2006 16:28:21 -0400

> http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01745.html

AFAICT, everything in that post is addressed in the current (and  
past) drafts.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 7 Jul 2006 11:26:11 -0400

At 16:28 -0400 7/6/06, David Blacka wrote:
>AFAICT, everything in that post is addressed in the current (and past) drafts.

(I've had this reply open for quite a few hours now...)

1) The original question was "where was the discussion."  That's a 
procedural question, not really important to the science of this, but 
Sam seemed to be picking on such a large change to a WG document 
without a WG mention of it.

Of course, raising this is like me trying to deflect the discussion 
at hand.  I don't mean to do that, but it's what has led us into this.

2) I've said it earlier that I have no problem with this as an 
experimental document, although I have reservations still if this 
will be a good thing.  In the spirit of "it's never too late to make 
a comment on a topic, but it's too late to comment on a document" 
what is being said here ought not delay the document - especially 
because it is experimental.

I'm not saying that experimental has a lower bar, but, it's that I 
really am not yet sold on *whether there is a problem* with opt-in.

3) Okay, here's the new material.

There's been the discussion of wild cards and opt-in for a while. 
(Yeah, I know there have been replies saying "it's a non issue" but I 
still don't agree.)  But here's a thought based on what's come up in 
the time since the above thread and now.

We say that only delegations can be opt-ed out.  We also say that you 
can't wild card NS sets - or rather we say you shouldn't think about 
doing it.  That's what's in the wcard to-be-RFC.  So, in a way, the 
conflict between wild cards and opt-in has been deflected.

But then I began thinking about the comment "Note that being able to 
add a delegation is functionally equivalent to being able to add any 
record type" that appears in the draft.  Well, maybe it's 
functionally equivalent, but a verifier can detect this, so maybe 
another non-issue.  So, maybe the non-conflict still holds.  OTOH, 
this could be a can of worms.

Ultimately, all of this is supposed to be for the benefit of the 
resolver/client/verifier.  If a response returns an unsigned 
delegation, does a proper answer include proof that there is no 
appropriate wild card?

Given that we are on an IETF-eve, maybe we can talk about this next 
week.  It's also probably in the document details and I've missed it.

---

From: David Blacka <[email-masked]>
Date: Fri, 7 Jul 2006 13:49:13 -0400

On Jul 7, 2006, at 11:26 AM, Edward Lewis wrote:

> (Yeah, I know there have been replies saying "it's a non issue" but  
> I still don't agree.)  But here's a thought based on what's come up  
> in the time since the above thread and now.
>
> We say that only delegations can be opt-ed out.  We also say that  
> you can't wild card NS sets - or rather we say you shouldn't think  
> about doing it.  That's what's in the wcard to-be-RFC.  So, in a  
> way, the conflict between wild cards and opt-in has been deflected.

> But then I began thinking about the comment "Note that being able  
> to add a delegation is functionally equivalent to being able to add  
> any record type" that appears in the draft.  Well, maybe it's  

A verifier is not required to detect this.  Well, specifically, a  
validator isn't required to detect that there was an actual insecure  
delegation present.  This is actually a change between opt-in-09 and  
earlier drafts.

> delegation, does a proper answer include proof that there is no  

No.  This is why section 8 talks about being able to replace a  
positive wildcard response with  a spoofed unsigned delegation, or  
vice-versa.

If there were proof that there was no appropriate wildcard, that  
would suggest that the wildcard would match before the delegation,  
which isn't true.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 7 Jul 2006 14:31:22 -0400

At 13:49 -0400 7/7/06, David Blacka wrote:

It's not so much a matter whether a verifier is required to do 
something (it's all up to local policy after all) but whether the 
verifier is presented with the data to make the (or any) question 
decidable.

>If there were proof that there was no appropriate wildcard, that would suggest
>that the wildcard would match before the delegation, which isn't true.

Now I recall that debate...existence vs. security.

Yes, if there is a genuine opt-out delegation in the zone then 
there's no wild card that comes into play.  But in this case, if what 
we are "defending" against is someone inserting an opted-out 
delegation, then showing that there's no applicable wild card is the 
data needed to disambiguate between malicious behavior and a regular 
answer.

Sure, the proof that there's no wild card can be stripped out.  But 
so long as the verifier is in the state of not seeing what should be 
there, it'll know to be suspicious.

Of course, if there is no wild card and someone is spoofing unsecured 
delegations, they all they need to do here is to replay the proof of 
no wild card and shove it into the forged response.  Not too hard to 
do, so maybe it isn't of any value.  Worse yet, a false sense of 
security and all.  But then again, if there is a wild card, then the 
attacker would have to forge the proof there is none, so maybe it's 
useful after all.

Every time I think this is all covered, another problem slips out.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: David Blacka <[email-masked]>
Date: Fri, 7 Jul 2006 15:47:52 -0400

On Jul 7, 2006, at 2:31 PM, Edward Lewis wrote:

>> would suggest
> there's no wild card that comes into play.  But in this case, if  
> what we are "defending" against is someone inserting an opted-out  
> delegation, then showing that there's no applicable wild card is  
> the data needed to disambiguate between malicious behavior and a  
> regular answer.

You cannot defend against someone inserting an opted-out delegation.   
That is one of the main properties of opt-in.  From the validator's  
point of view, there is no discernible difference between a real opt- 
out delegation and a spoofed one.

> so long as the verifier is in the state of not seeing what should  
> be there, it'll know to be suspicious.

By going down this path, you would make wildcards and opt-in  
completely incompatible.

> Of course, if there is no wild card and someone is spoofing  
> unsecured delegations, they all they need to do here is to replay  
> the proof of no wild card and shove it into the forged response.   
> Not too hard to do, so maybe it isn't of any value.  Worse yet, a  
> false sense of security and all.  But then again, if there is a  
> wild card, then the attacker would have to forge the proof there is  
> none, so maybe it's useful after all.
>

No, I think that you just aren't accepting the opt-in tradeoff.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 7 Jul 2006 16:05:00 -0400

At 15:47 -0400 7/7/06, David Blacka wrote:

>That is one of the main properties of opt-in.  From the validator's point of
>view, there is no discernible difference between a real opt-out delegation
>and a spoofed one.

You can never defend against someone attempting an attack, that's true.

The question is whether it is possible to arrange the protocol to 
indicate the difference, and I think the answer is no.

But...

>By going down this path, you would make wildcards and opt-in completely
>incompatible.

How so?

>No, I think that you just aren't accepting the opt-in tradeoff.

Of course not, I don't like tradeoffs.  So I'm resisting until I'm 
convinced it isn't a tradeoff but a necessary solution.

However, your reply isn't addressing what I think can be solved - the 
conflict between having a signed wild card in the zone and some 
spoofing in an answer.  The spoofed referral shouldn't be able to 
trump a signed answer, or signed no data answer.

---

From: David Blacka <[email-masked]>
Date: Fri, 7 Jul 2006 17:17:32 -0400

> You can never defend against someone attempting an attack, that's  

That isn't what I meant.

> indicate the difference, and I think the answer is no.

The answer is no.

>> completely

1. You cannot tell the difference between a spoofed opt-in delegation  
and a real one.
2. You propose for the validator to check for proof that no wildcard  
could have matched when validating an opt-out referral.
3. But, there is no difference between the spoofed case and the real  
case (see #1).
4. Thus, if there is a wildcard in an opt-in zone, then you cannot  
have any insecure opt-out delegations, since you won't be able to  
prove that the wildcard shouldn't have matched.

That is, if your proposal will block a spoofed referral, it will also  
block a real one.

> convinced it isn't a tradeoff but a necessary solution.

This is a natural consequence of what opt-in is.  Within the opt-in  
span, an attacker can (by spoofing) insert a name.  That spoofed name  
may be used to block the expression of the wildcard.  Within an opt- 
in span, an attacker can remove insecure names, allowing the wildcard  
to be expressed.

The attacker can do this because of what an opt-in span *means*.  It  
means that insecure names are not proven to exist or not exist.

> However, your reply isn't addressing what I think can be solved -  
> the conflict between having a signed wild card in the zone and some  

I think that this is all adequately described in section 8 of the draft.

However, the statement "The spoofed referral shouldn't be able..." is  
exactly what I was talking about when I said that you just haven't  
accepted the opt-in tradeoffs.  In your mind it shouldn't, but with  
opt-in it can, and the fact that it can is documented as a tradeoff.

So, I don't see this as a *conflict* but as a caveat.  It isn't that  
opt-in prevents you from using a wildcard, it is that you don't get  
the same security guarantees with wildcards as you do with normal  
signed authoritative data.

You are, of course, free to invent some alternative proposal that has  
the properties you want.  Opt-in has the properties that it does  
because of the approach it took.  If you want different properties, I  
think that you are going to need a different approach.