Subject: Re: [DNSOP] 4641bis (draft 3 and 4) review - largely 5011 related

From: Olaf Kolkman <[email-masked]>
Date: Wed, 20 Oct 2010 14:16:39 +0200

Clearly I am trying to get a (hopefully WG last call ready) version 05 of the document out by the deadline.

Some comments in-line based on specific feedback you provided.

On Aug 5, 2010, at 9:43 AM, Matthijs Mekking wrote:
> 
> The KSK RFC5011-based rollover method says that the removed key must be
> post-published as revoked at least holdback timer long. However, that
> parameter is just a management value for the validating resolver. It
> should be post-published as revoked the Maximum Zone TTL long. Proposed
> text:
> 
>   RFC5011 increases the duration of key rollovers, because the
>   key to be removed must first be revoked. Thus, before the DNSKEY1
>   removal phase, DNSKEY1 must be published for one more Maximum Zone
>   TTL with the REVOKE bit set. The revoked key must be self-signed, so
>   in this phase the DNSKEY RRset must also be signed with DNSKEY1.

ACK, this proposed text  (modulo some stylistic differences) is added to version 5.

> 
> This is also true for algorithm rollover. Proposed text:
> 
>   Trust anchor algorithm rollover is as simple as a regular RFC5011
>   based rollover. The old trust anchor must be revoked before it is
>   removed from the zone.
> 
>   However, at every RRset there must be at least one signature for
>   each algorithm used in the DNSKEY RRset. This means that a different
>   key with the same algorithm, other than the revoked key, must
>   sign the entire zone. This can be the ZSK. More operations is
>   needed if the single type signing scheme is used. Before rolling the
>   algorithm, a new key must be introduced with the same algorithm as
>   the key that is candidate for revocation. That key can than
>   temporarily act as ZSK during the algorithm rollover.
> 

ACK. this is added too. 

> End proposed text.
> Rolling the algorithm of only the KSK or only the ZSK is in my point of
> view infeasible and useless.
> 
> And one more RFC 5011 note: In section 4.2.3 (Compromise of Keys
> Anchored in Resolvers), it might be relevant to mention that RFC5011 can
> also recover from compromised keys, as long as at least one valid
> trust-anchor key remains uncompromised.

Hmm.. but the compromiser can also initiate a rollover. Therefore I am not sure if the word "recover" is correct in this context.

> 
> Finally, some editorial nits in version 4:
> - - You replaced the names of the DNSKEYs in the tables (for example,
> DNSKEY_1 becomse DNSKEY_Z_1), but not in the text.

ACK

> 
> - - In the ZSK pre-publish rollover method, at the DNSKEY removal stage,
> the text says re-sign with DNSKEY1. Although not necessary, it should
> also be re-signed with DNSKEY11 (DNSKEY_Z_11), because it does so in the
> table.
> 

ACK

> - - In the ZSK double signature rollover method, at the DNSKEY removal
> stage, the text says "The key set now only containing DNSKEY 11, is
> re-signed with DNSKEY 1." Again, also resign with DNSKEY_Z_11. Also, the
> key set also containst DNSKEY_Z_11.
> 

ACK

> Below are some more inline comments.

[skip]

On a point about RFC5011 text you remark:
> 
> The text now says:
>   It is therefore recommended to roll KSKs that are likely to be used
>   as trust-anchors if and only if those rollovers can be tracked using
>   standardized (e.g.  RFC5011) mechanisms.
> 
> To avoid confusion, I would add "on a regular basis" here.

ACK 

[skip]

--Olaf

________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140, 
http://www.nlnetlabs.nl/               1098 XG Amsterdam