Subject: Re: DNSSECbis Q-12: Support for multiple preconfigured public keys in a security-aware resolver (fwd)

From: Ólafur Guðmundsson <[email-masked]>
Date: Fri, 25 Jul 2003 10:09:35 -0400

Sam has been unable to post this on namedroppers himself, so he asked me
to forward this message.

         Olafur

>Date: Tue, 22 Jul 2003 18:10:28 -0400 (EDT)
>From: Sam Weiler <[email-masked]>
>To: [email-masked]
>Subject: Re: DNSSECbis Q-12: Support for multiple preconfigured public keys
>  in a security-aware resolver (fwd)

[I've seen this bounce twice.  If it actually got through and you're
seeing a duplicate, my apologies.]

 > Q-12: Should support for configuring multiple trusted public keys in a
 > security-aware resolver be a MUST rather than a SHOULD?

A security aware resolver is unlikely to be very useful without this
capability, but does omiting it negatively impact the protocol?  It
doesn't affect the on-the-wire bits.  "Constraining users" doesn't
justify a MUST.  If, however, having only one configured key would
effectively prevent key rollover (as in, rollover of the one true root
key), then we need to be concerned.

Imagine this scenario:  the root wants to roll its key.  Having
clients with only one configurable key mean that the root must sign
with both keys during the transition window.  If all clients can
configure multiple keys, they can add the new one before it's actually
in use, the root can make the change all at once, and everyone who has
updated their keys keeps on going, removing the old keys at their
leisure.  Is it valuable for the root (or any zone who's key will be
configured in end clients) to be able to roll over all at once?  With
the layer of indirection (SEP/ZSK) introduced by DS, it's not
manadatory -- it's tractable to sign a KEYset with multiple KEYs for
an extended time.  Except that those extra signatures may make packets
big.  With 2535, if the secure entry point was, say, .com, then
keeping the whole zone signed with multiple keys would not be
tractable.

Summary: I don't see a jutification for a MUST.  Or even a SHOULD.
This is implementation advice, not protocol requirement.  It should be
there, but it's not critical to interoperability.

-- Sam

--
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: Mike StJohns <[email-masked]>
Date: Fri, 25 Jul 2003 10:29:17 -0400

Sorry - wrong answer.  MUST is correct.

MUST is used to indicate features to implementers that if omitted, 
adversely affect the operation of the protocol *or system*.  While the 
omission of this might not have an adverse affect on the protocol bits on 
wire stuff, it most definitely does have an effect on the system.

This is not a key rollover issue - its an island of trust issue.  There 
will not be one true root for a long time to come and a resolver needs to 
be able to configure multiple trust anchors at different points in the tree.

Mike

---

From: "Scott Rose" <[email-masked]>
Date: Mon, 28 Jul 2003 10:21:21 -0400

I agree with StJohns on this.  It should be a MUST.  If a resolver cannot
handle 2 or more pre-configured DNSKEY RRs, There is no way it can handle
more than one island of security, or even more than one signing algorithm.

I believe that the text should state that support for multiple preconfigured
DNSKEY/DS hash be a MUST.

Scott