Subject: Re: [DNSOP] WGLC <draft-ietf-dnsop-rfc4641bis-06.txt> [2011-05-17] Section 4.1.4

From: "George Barwood" <[email-masked]>
Date: Mon, 9 May 2011 07:22:32 +0100

I have a comment about section 4.1.4.  Rollover for a Single Type Signing Key rollover.

The following simple scheme  doesn't seem to be covered.

(1) Introduce new key DNS_K_2

(2) Add DS record for DNS_K_2 to parent zone.

(3) Wait for DNS_K_2 and it's DS record to propagate.

(4) Stop signing with DNS_K_2, start signing with DNS_K_1

(5) Wait for DNS_K_2 signatures to propagate.

(6) Remove DNS_K_1 from child it's DS record from parent.

This has the advantage of minimising the size of the signed DNSKEY response,
to 2 x DNSKEY and 1 x RRSIG, and doesn't involve double signatures.

It is double-DS, but given that DS records are relatively small, this may be a lesser consideration,
whereas the size of the DNSKEY response is most likely to be affected by fragmentation/TCP fallback
considerations.

George Barwood

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 09 May 2011 08:48:10 +0200

Hi George,

No comment on section 4.1.4, but wanted to note a mistake in your post.

> (4) Stop signing with DNS_K_2, start signing with DNS_K_1

Start signing with DNS_K_2 and stop signing with DNS_K_1

> whereas the size of the DNSKEY response is most likely to be affected by fragmentation/TCP fallback

Best regards,
   Wouter

---

From: "George Barwood" <[email-masked]>
Date: Mon, 9 May 2011 07:47:44 +0100

> (4) Stop signing with DNS_K_2, start signing with DNS_K_1

Apologies, that should of course be

(4) Stop signing with DNS_K_1, start signing with DNS_K_2

George

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 25 May 2011 11:30:56 +0200

Hi Marc,

Sorry for the late response.

On 04/19/2011 02:31 PM, Marc Lampo wrote:
> Some comments :
> 
> 3.1 Operational Motivation for ZSK and KSK
> 
> I explicitly agree with Antoin Verschuren [[email-masked]] that
> more criteria should be taken into account, more then listed in the
> present document (like the ones he proposes).

I am not sure to which terminology you are referring to. Could you point
me out?

> As extra observation, I would prefer "child-parent" rather then
> "registrar-registry" (globally : any reference to "registrar" or
> "registry").
> Motivation : registrar is linked to the "customer" layer and "registry" to
> the "tld" layer of a "customer.tld." domain name.  But DNSSEC can go below
> that level !  As I am in Belgium, "just.fgov.be." is a delegated subdomain
> : if they will, one day, soon ?, implement DNSSEC, the communicating DS
> information is not between registrar and registry.
> In broader scope : the document should not limit to DNSSEC between a label
> and a top-level-domain (or tld - root-domain).

I am replacing the registrar-registry terms with child-parent on those
places where the text is talking in a more general scope.

> 4.1 Key Rollovers
> 
> For non-tld's, I agree, again, with Antoin Verschuren
> [[email-masked]] : recommend double-sign rollover.
> 
> The present document states, "neutrally", that double-sign rollover
> involves more signatures and hence, larger zone files.  While this is
> true, well maintained (public) zone files should be small anyway (except
> for tld's).
> The average company does not offer hundreds of services on hundreds of IP
> addresses.
> 
> A DNS administrator who leaves data like "test-mx" in hers or his public
> data should learn not to publish anything not meant to be distributed.
> Recommending pre-publish for "large" zone files (with "lots" of
> unnecessary data in it) is "pearls to the pigs" ;-)

As said earlier by Paul and Antoin, I too am against such recommendation.

> 4.1.2 Key Signing Rollovers
> 
> I see some tld's perform rollover with 3 keys (not 2).
> 
> Assuming a start position with 2 keys :
> Initial : KSK1 & KSK2 (both being used for signing)
> Start of rollover : add KSK3  --> KSK1 & KSK2 & KSK3 (all used for
> signing)
> End of rollover : remove KSK1 --> KSK2 & KSK3 (both used for signing)
> Advantage :
>  Only 2 actions to complete key rollover
>  During the rollover, there is one key that is completely untouched.
>  --> if chain-of-trust would break via KSK1 or KSK3, that KSK2
> (DS/DNSKEY/RRSIG) is always available.
> 
> As the KSK signs only the DNSKEY RRset, this "costs" only one extra RRSIG
> in the zone file.

To me, this sounds more like a Double-Signature Rollover variant, where
there is a third key 'hanging around'.

Thanks for your review.

Best regards,
  Matthijs

> 
> 
> Kind regards,
> 
> Marc Lampo
> 
> 
> 
> -----Original Message-----
> From: Peter Koch [mailto:[email-masked]] 
> Sent: 18 April 2011 07:42 PM
> To: IETF DNSOP WG
> Subject: [DNSOP] WGLC <draft-ietf-dnsop-rfc4641bis-06.txt> [2011-05-17]
> 
> Dear DNSOP WG,
> 
> this is to initiate a working group last call (WGLC) on
> 
> 	"DNSSEC Operational Practices, Version 2"
> 	  <draft-ietf-dnsop-rfc4641bis-06.txt>
> 
> Owing to the length of the document, the WGLC will last for four weeks
> instead of the usual two, and will therefore end on
> 
> 		Tuesday, 17 May, 23:59 UTC.
> 
> The IETF tools site gives easy access to the current and previous
> versions as well as differences and the like at
> 
> 	<http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-06>.
> 
> The document is aimed at a status of "Informational".
> 
> Please review the document and send any comments you may have to the
> list.  If you have no comments but support (or do not support) the
> document being published, please send that information to the list.
> 
> The document is subject to the normal five reviewer threshold.
> 
>     Stephen and Peter
>      DNSOP co-chairs
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 26 May 2011 11:23:44 +0200

Hi George,

Yes, this seems to me to be a valid rollover scheme. Essentially it is a
second variety of the Double-DS rollover, where a KSK Double-DS rollover
is combined with ZSK Pre-Publish rollover.

Section 4.1.4 does provide text on a second variety of the
straightforward STSS rollover, where the new key only signs the DNSKEY
set, not the other RRsets. When the new DNSKEY has propagated, you
replace the signatures of K_1 with those of K_2. The so-to-say CSK is
temporarily considered a ZSK. That text also mentions that in this case,
a KSK/ZSK split may be a better option.

Basically, you describe a second variety of the STSS Double-DS rollover.
In your scheme, the new CSK is also temporarily considered a ZSK. So,
perhaps in this case, it is also advisable to use a KSK/ZSK split option.

I would like to propose the following text to add at the end of section
4.1.4:

   There is also a second variety of the Double-DS rollover during
   which one introduces a new DNSKEY into the key set and submit the
   new DS to the parent. The new key is not yet used to sign RRsets.
   One replaces the DNSKEY_S_1 signatures with signatures
   made with DNSKEY_S_2 at the moment that DNSKEY_S_2 and DS_S_2 have
   been propagated.

   Again, this second variety of this rollover can be considered when
   zone size considerations prevent the introduction of double
   signatures over all of the zone data although also in this case,
   choosing for a KSK/ZSK split may be a better option.

Best regards,

Matthijs