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

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

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