Subject: Re: Delegation Signer Resource Record

From: Derek Atkins <[email-masked]>
Date: 28 Oct 2002 22:46:55 -0500

Olafur Gudmundsson <[email-masked]> writes:

> On Mon, 28 Oct 2002, Edward Lewis wrote:
> 
> > At 17:50 -0500 10/28/02, Olafur Gudmundsson wrote:
> > >sorry, you are wrong, DS requires two validations
> > >	one for DS set and one for KEY set.
> >
> > parent:
> > @      KEY1
> >         KEY2
> >         SIG(KEY) by KEY1
> > child  DS(KEY3)
> >         SIG(DS) by KEY2
> >
> > child:
> > @      SOA
> >         SIG(SOA) by KEY3
> >         KEY3
> >
> > Why must KEY3 be signed?  I know that if "SIG(KEY3) by KEY3" exists,
> > you get a warm and fuzzy feeling, but is it's existence a MUST?
> 
> So, other bogus can not insert other keys into the KEY set and then use
> them to sign data generated by the attacker.
> Having the child KEY set signed by a "known key" whole reason, DNSSEC is
> about providing data integrity and authentication.

Yes, but KEY3 _IS_ signed -- through the DS in the parent.  An
attacker couldn't supply a "KEY4" because it would not be tied into
the parent's DS hierarchy.

OTOH, note that if you _DO_ have a KEY4 in the child zone you _DO_
require a "SIG(KEY) by KEY3" record...  So it may be easier to always
include it "just in case".  However KEY3 can certainly stand "alone"
without a self-signature -- it's validity is certified by the
DS/SIG(DS) in the parent.

-derek

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

--
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: Edward Lewis <[email-masked]>
Date: Tue, 29 Oct 2002 08:35:04 -0800

Okay - there's "A secure zone MUST contain a self-signed KEY RRset at 
its apex." in the draft.  This means that the DS RR approach will 
always incur the extra SIG check.

(But the question remains - is it necessary?)

>them to sign data generated by the attacker.

If there KEYX is a bogus key, and it is slipped into the KEY RR set, 
so long as the DS(KEY3) does not point to a SIG(KEY) by KEYX, what's 
the problem?

>about providing data integrity and authentication.

But the DS refers to a specific key.  And, if the attacker could 
forge a SIG(KEY by KEY3 that does cover {KEY3, KEYX}, the attacker 
might as well just forge SIG(DATA) by KEY3.

I don't think that the SIG(KEY) is needed if there's just one KEY RR 
in a set that is referred to by a DS RR.

>>  Do I get the DS for arpa and in-addr.arpa in the referral?  I'm
>>  asking in the context of this text in 2.2:
>>
>>  #   If DS RRset is present:
>>  #        parent NS RRset
>>  #        DS and SIG(DS)
>
>Only the one it is returning NS records for.
>In this case 128.in-addr.arpa. NS [and DS set].
>
>	Olafur

Then specify that only the DS RR set of the (what's the term?) zone 
in the referral is sent.  Or open this up to requiring that all DS 
RR's at the server are to be returned.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer