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

From: Matthijs Mekking <[email-masked]>
Date: Thu, 05 Aug 2010 09:43:42 +0200

There seems something went wrong with the layout on the previous try...

Matthijs

- -------- Original Message --------
Subject: 4641bis (draft 3 and 4) review - largely 5011 related
Date: Thu, 05 Aug 2010 09:42:14 +0200
From: Matthijs Mekking <[email-masked]>
To: [email-masked]

Hi Olaf,

I noticed there is already a version 4 out, but it merely covers changes
in language and style. So, here is a review of version 3 of the document.

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.

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.

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.

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.

- - 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.

- - 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.

Below are some more inline comments.

Best regards,

Matthijs

On 07/20/2010 06:20 PM, Olaf Kolkman wrote:
>> > > - Point 1:
>> > > Is the set of arguments presented for major operational choices (e.g.
single versus ksk-zsk split,
>> > > and key effectivity period) complete and are the arguments fairly
represented?

...

>> > > Addressing all these arguments and considerations has created a
fairly
long document.
>> > > In fact the choice has been to make the document comprehensive in
presenting the considerations
>> > > while not giving strong recommendations one way or another. This
causes the document to be rather
>> > > long and raises the question of the target audience.
IMO, I think it is relevant to present the reader with the possible
options, including all its drawbacks and advantages. Later on, the
reader can always seek into the document to find the section they deployed.

>> > > Also see:
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/KSK-ZSK-Split
>> > >
>> > > - Point 2:
>> > > Should this document try to give strong recommendations or should a
separate document (set) be made that gives
>> > > recommendations for certain operational environments (e.g. BCP for
root, BCP for TLD, BCP for enterprise)?
>> > > I am looking for specific guidance but as a straw man for consensus:
This document should not give strong
>> > > recommendations but provide comprehensive arguments (like it does
now); development of recommendations is
>> > > left for later, either in a follow up (RFC4641bis-bis) or as a set of
separate documents)

Based on the previous comments: yes.

>> > > -Point 3:
>> > > There have also been some questions about what audience the document
is trying to address.
>> > >
>> > > The document is targeted to the 'the authoritative side of the DNS
equation'. Is that indeed what the WG wants?
>> > > If so is that clear enough from the document. (Please send concrete
suggestions to improve if not).

Yes.

>> > > If there is consensus that the document talks to the authoritative
side then the chairs may want to ask the
>> > > question as to whether there a need for separate guidance for
resolver
operators, and maybe even ask for volunteers ;-)
>> > >
>> > >
>> > > The following points are more detailed.
>> > >
>> > > -Point 4:
>> > >
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration
>> > >
>> > > Version 3 of the document has tried to address these issues
(pending a
conclusion of point 3 above) but in order
>> > > to close this issue I would like to know whether "the document
[is] in
any way restrictive on not using 5011,
>> > > or is its consideration for advising RFC5011 to strong?" Silence on
this point will be taken as finding the right balance.

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.

>> > > -Point 5:
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Signature_validity
>> > > Text added in 4.4.2, is this text satisfactory
>> > >
http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-03#section-4.4.2
>> > >
>> > > The paragraph talks about a Maximum signature validity and Minimum
validity period in fairly broad terms.
>> > > It also provides motivations for differentiating Signature Validity
periods for different RRsets in a zone,
>> > > those motivations are few and week.
>> > >
>> > > Again, is this section complete in providing arguments and are the
arguments fair? If not, what are concrete
>> > > recommendations for improvement.
I am fine with the text in this section/

>> > > - Point 6
>> > >
>> > > Is Appendix B useful? Or drop it?
Already dropped in version 4, I see. Good.

>> > > - Point 7
>> > > Any objections on closing the following:
>> > > -
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Key_algorithm_roll

Yes, since the issue with RFC5011 popped up during ietf78.

>> > > -
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll-frequency
>> > > (take a look at 3.1.1.  Motivations for the KSK and ZSK Separation,
the last paragraphs)
>> > > -
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/differentiation_trustanchor_parent
>> > > -
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/discussion_of_timescales
>> > > -
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/non-cooperative-registrars
>> > > -
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/rollover_assumptions
>> > > -
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_and_parent_keys
>> > > I think this issue has become obsolete.
>> > >
>> > > Since some of these issues are hard to relate to version 3 of the
draft I would like to
>> > > take the following approach for version 4 of the I-D: mark all above
issues as completed,
>> > > unless I receive further clarification on why I shouldn't (possibly
with suggested text),
>> > > open new issues relative to version 3 of the draft, address those in
version 4.
>> > >
>> > > My target is to have version 4 of the document last call ready. That
is all major issues out of the way, and only nit-fixing.
>> > >
>> > > I am aware of a number of editorial nits[*]
>> > >
>> > > --Olaf
>> > >
>> > > [*] See http://www.secret-wg.org/draft-ietf-dnsop-rfc4641bis.txt
for a
snapshot of the living document and http://tiny.cc/6sllt
>> > > for the difference between the living document and the draft
version 3
as it lives in the repository.
>> > >
>> > > ________________________________________________________
>> > >
>> > > Olaf M. Kolkman                        NLnet Labs
>> > >                                        Science Park 140,
>> > > http://www.nlnetlabs.nl/               1098 XG Amsterdam
>> > >
>> > > _______________________________________________
>> > > DNSOP mailing list
>> > > [email-masked]
>> > > https://www.ietf.org/mailman/listinfo/dnsop

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 05 Aug 2010 17:11:00 +0200

Algorithm rollover is also discussed on namedroppers. Wouter listed some
other options you have when algorithm rollover and 5011 are both in place:

* Go MISSING.
use the steps for removal without the REVOKE publish step.  The key goes
into 5011-MISSING state.  And is removed after a time (180 or 366 days
or so).  This may be an alternative for non ZSK-KSK split zones, since
they want things easy, and this is easy.

* Sign the entire zone with the removed KSK while it is REVOKED as well.
Some find this distasteful, but really, it is only a DNSKEY flag, just
like the SEP flag and carries meaning only to operators.  If you have a
ZSK/KSK split you do not have to do this.

! The latter option is, I believe, not true. If you do not introduce a
  temporary ZSK, you will break 5011-aware resolvers (since they will
  stop using the revoked key for validation and now theres only
  signatures of one algorithm validating). So even with a single type
  key scheme, you need to introduce a (temporary) split when doing
  algorithm rollover.

  Nevertheless, I think the first option is nice to include into
  4641bis.

Best regards,
Matthijs

On 08/05/2010 09:43 AM, Matthijs Mekking wrote:
> -------- Original Message --------
> - You replaced the names of the DNSKEYs in the tables (for example,
> - In the ZSK pre-publish rollover method, at the DNSKEY removal stage,
> - In the ZSK double signature rollover method, at the DNSKEY removal