Subject: Re: DNSSEXT Yokohama Minutes

From: Edward Lewis <[email-masked]>
Date: Sat, 14 Sep 2002 10:43:16 -0400

At 10:01AM +0200 9/4/02, Roy Arends wrote:
>Note that wildcards are in a zone, delegation points are outside a zone,
>therefor you can't use wildcard delegations, and thus no proof for
>existing wildcard delegation is needed.

Question is: does an signed wildcard trump an unsigned delegation name?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

--
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: "Scott Rose" <[email-masked]>
Date: Mon, 16 Sep 2002 09:54:48 -0400

----- Original Message -----
From: "Edward Lewis" <[email-masked]>

> Question is: does an signed wildcard trump an unsigned delegation name?

I think it should - wildcards can be signed, and considered authoritative in
a zone.  Since delegations aren't, it could be spoof (but hopefully detected
later).

A resolver can verify a signed wildcard, but not a delegation.

Scott

---

From: Roy Arends <[email-masked]>
Date: Mon, 16 Sep 2002 16:04:21 +0200 (CEST)

> Question is: does an signed wildcard trump an unsigned delegation name?

No, I don't think that is the question.

The signer of the zone has give proof that there exist no signed material
in an interval. All bets are off if you query for a record that is not
signed [1]. If the signer of the zone wants to use signed wildcards, she
should know that they can be used to spoof within unsigned intervals.

[1] Note that the response has a signed statement that the interval is not
    secure.

Proof of wildcards in a response with positive unsigned referals leads to
nothing more than ambiguity.

Roy

---

From: Derek Atkins <[email-masked]>
Date: 16 Sep 2002 10:10:09 -0400

> Question is: does an signed wildcard trump an unsigned delegation name?

What do you mean?  You cannot have a "*.example IN NS ..." record.
The fact that you have a signed "*.example IN MX ..." record has
nothing to do with the fact that you've got an unsigned "foo.example
IN NS .." record.

How would this trumping even happen?  The RTYPEs are different.

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Edward Lewis <[email-masked]>
Date: Mon, 16 Sep 2002 10:40:41 -0400

>How would this trumping even happen?  The RTYPEs are different.

The trumping is whether the algorithm for looking up replies first 
checks the signed data only (hence finds the wildcard) or looks 
through all the data.

---

From: Derek Atkins <[email-masked]>
Date: 16 Sep 2002 11:15:42 -0400

> checks the signed data only (hence finds the wildcard) or looks

The algorithm at the server or at a cache?  An authoritative server
still looks at the QNAME first.  If it finds an entry for the QTYPE,
it uses it.  It not, it checks the wildcard.

The fact that opt-in is in use doesn't change this.  Remember: only NS
records can live within an opt-in interval.  This means that the
potential states you have are:

1) signed RDATA at the QNAME and signed wildcard
        RDATA wins
2) no RDATA at QNAME and signed wildcard
        wildcard wins, but must provide the QNAME NXT
3) no RDATA and no wildcard
        NXDOMAIN; must provide both (all?) NXTs

The fact that the NXT is opt-in or not does not matter, because the only
record that can live in an opt-int interval is an NS, and you cannot have
wildcard NS.  If the QTYPE is NS, then you can ignore wildcards completely.

-derek

---

From: Edward Lewis <[email-masked]>
Date: Mon, 16 Sep 2002 11:34:03 -0400

>         wildcard wins, but must provide the QNAME NXT

That's wrong - NODATA @ QNAME wins...once the name matches, I stop searching.

>         NXDOMAIN; must provide both (all?) NXTs

That should be no explicit QNAME and no wildcard
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer