Subject: Re: Comments on draft-stjohns-dnssec-trustupdate-00.txt

From: Mike StJohns <[email-masked]>
Date: Fri, 14 May 2004 11:20:00 -0400

Resending from a subscribed address..

At 09:30 AM 5/14/2004, Gilles Guette wrote:

>>>Did I miss something?
>>
>>I believe both the SEP1 and SEP2 keys are supposed to be active for a time.
>>The overlap allows resolvers (validators) to learn and validate the new SEP
>>key before installing it as a trust anchor.  That is the impression I got.

Yes.  Without the add hold down, there's an interesting attack if one of 
the keys is compromised..  So the zone owner needs to do some preparation 
by having multiple trust anchors.

>In this case, I think that this model is not suitable for zone files 
>having only one SEP, because if a zone has one SEP and want to change it, 
>the owner of the zone must first create a new SEP and wait 30 days and 
>after revoke the old SEP.
>
>In the same way if a zone has 2 SEP (SEP1 and SEP2) and want to change 
>one. The zone owner revoked SEP1 and create SEP3, it is OK but during the 
>next 30 days this zone can not change SEP2 because of the same problem.

Correct.  Again, the zone owner has to do some prep.

You asked in a previous email about the number of keys.  For critical zones 
you may want to have three trust anchors - an active and two stand by  (A, 
B, C).  Say C is compromised you can do (A, B, REVOKE(C), D) 
sign(A,C).   The new key set will be A, B, D with A continuing to be the 
active signer.  If A is then compromised before the hold down expires, you 
do (REVOKE(A), B, REVOKE(C), D, E) sign (A,B,C).  At that point you're 
stuck for at least 30 days until D and E are accepted as trust anchors, but 
you were able to manage the multiple compromises.  (Note that the timer on 
accepting D was reset once the resolver saw the (REVOKE(A))sign(a)).

Later, Mike

--
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, 14 May 2004 11:19:20 -0400

Resending from a subscribed email address...

At 08:32 AM 5/14/2004, Scott Rose wrote:
>I have some comments of my own:
>
>meta comment - The DNSSECbis docs have seperated the "resolver" and
>"validator" roles.  Adding some complexity to avoid confusion :)  The
>resolver would learn of the new SEP key, but the validator would be the one
>that would rollover the trust anchor.

I think that's implementation detail.  The validator can still get data 
from the resolver.  Is there something specific that should be said?

>Section 2.4.2
>"This ensures that at least two DNSKEY RRSets MUST be seen by the
>resolver..."  2 RRsets?  Isn't it one set, with some keys having different
>flags set?

Hmm... badly worded.  What I meant was that the resolver has to see the new 
DNSKEY in the RRSet twice - and at least one of those had to be after the 
expiration of the TTL in which the DNSKEY first appeared.  E.g. the 
resolver has to fetch the DNSKEY RRSet at least twice at different times 
from the zone servers.

>Section 5.1
>Should the zone signing key be set at generation time as well?  Or is there
>a specific time that is set?  Is there a time when the REVOKE bit is set and
>the ZSK is cleared (and RRSIGs removed)?

My reading of the documents may be confused, but I thought the ZSK was 
necessary to validate a signature, but there's no requirement that there be 
associated signatures for any key  In any event if the ZSK needs to be set 
for the SEP bit to be set then I can note that here.

>Section 6.1
>"...decision whether to accept a replacement trust anchor key based on trust
>for a current trust anchor key..."  Sounds confusing, but don't know how to
>rephrase to make it sound more clear.

I'll look at it again.

>second para:
>Why only manual updates?  Could that include some automatic method out of
>band for DNS?

Let me change "manual" to "out of band" to correct this.

>I think this is a good draft for consideration on key rollover.  It does
>require allocation of a new bit in the DNSKEY flag field, but that is easy
>since there is plenty of room.

Thanks.  And thanks for the excellent on-the-point comments.

Mike