[DNSOP] Review of draft-ietf-dnsop-rfc4641bis-02

[Andrew Sullivan <[e-mail]>]

Dear colleagues,

I have reviewed draft-ietf-dnsop-rfc4641bis-02.  These are my
comments.

First, I think the draft is largely in good shape, but there remain
some substantive issues in it that I think require work.  I do not
think there is enough "current practice" on the Internet to target BCP
status with this.  This is not ready for WGLC in my view, but might be
after another round.

There are several style, puctuation, and other such nits throughout
the document.  I haven't compiled them this time, because I suspect
some substantial changes are likely and some of those will inevitably
catch the existing ones or introduce new ones.

This review is basically section by section, with a few cross-references.

Intro: Should the references include NSEC3 (5155) also?
Cf. draft-ietf-dnsext-dnssec-bis-updates.

§1.1 insert "For instance" before "Where it is written"?

§1.2  "Signature publication period": This definition is
slightly counter-intuitive to me.  First, "published in the master
zone" is maybe not the best start time, because the master zone may
not actually be visible to anyone on the Net.  Moreover, if someone
queries an authority server and can _not_ get the new signature, that
also seems to be troublesome.  I'd like to suggest either that this
issue be noted, or that the definition be adjusted, or that the whole
thing refer to draft-morris-dnsop-dnssec-key-timing.  (I have a
similar feeling about para 3 in §2.)  There is such a reference in
4.1, but for the definition of the term it might be useful to make the
reference again.  Also, I'm pretty sure that the advice in §4.1.1
about the latest point at which you can re-sign is not going to work
using this definition, because (as 4.1.1 notes) the point at which
things start to break is the point when the new signatures aren't
available before the expiry of the old one: when the new one was
introduced to the network of nameservers isn't enough.

§3.1.1, NIT, "parental DS".  I hate this expression.  It's ugly.
There's no reason to use it, anyway, I think: the DS only appears in
the parent place in the chain (DLV works _in loco parentis_,
effectively).  Also, "In the case that a SEP key that ", s/case
that/case of/.

I have some grave doubts about the conclusion of this section.  It
seems to me that it marshalls weak arguments in favour of KSK/ZSK
separation and doesn't consider the counter-argument: that in many
situations, automated, non-automatic DS replacement means that
distribution happens fast enough, and in low-update-frequency zones it
is faintly mad to increase complexity without appreciably reducing
risk.  To my mind, therefore, this section would be better outlining
the different trade-offs, making recommendations for the extreme ends
of the trade-off spectrum, and then leaving operators to decide where
they fit.  That discussion happens in the subsequent sections.  Maybe
some of this should be merged together?  I'm not sure exactly what to
suggest as modification, but I think the conclusion here is stronger
than the subsequent discussion.

§3.1.2.1

NIT 
   o  It should be done frequently but irregularly.  Frequently meaning
      every few monthts, again based on the argument that a rollover is
      a practiced and common operational routine, but irregular, i.e.
      with a large jitter, so that 3rd parties do not start to rely on
      the key and will not be tempted to configure those as a trust-
      anchor.

The second sentence there is not actually a sentence.  I tried to
write new text, but then I realised that I didn't understand this.  If
the key rolls, nobody can be tempted to rely on "the key", since it's
just been replaced.  Is the idea that there is a well-known source for
the key and it gets updated all the time, and that you should do that
without regularity?

The text,

     On the other hand, the only completely effective way to tell
   if the communication is good is to test it periodically.  Thus,
   rolling a KSK with a parent is only done for two reasons: to test and
   verify the rolling system to prepare for an emergency, and in the
   case of an actual emergency.

seems to me to be just wrong, if it's supposed to be advice.  Do
people change their nameservers from time to time just "to be sure
communication works"?  In my experience, no.  I get the argument that
you exercise procedures to make sure they work, but given that we have
large numbers of examples throughout the DNS where we _don't_ do that
regularly, for certain kinds of zones, I'm extremely sceptical of this
as general-purpose advice.

§ 3.1.2.2

   The same operational concerns apply to the rollover of KSKs that are
   used as trust-anchors.  But remember: if a trust anchor replacement
   is done incorrectly, the entire zone that the trust anchor covers
   will become bogus until the trust anchor is corrected.

I think this should be changed to

   The same operational concerns apply to the rollover of KSKs that
   are used as trust-anchors.  But remember: if a trust anchor
   replacement is done incorrectly, and there is no other trust path
   to the zone or validators are configured to trust only the trust
   anchor and no other path, then the entire zone that the trust
   anchor covers will become bogus until the trust anchor is
   corrected.

I know that's more awkward.  I haven't come up with a clearer way of
saying it.

   The only remaining trade-off choosing an appropriatly long Key
   Effectivity Period which guards against a system that is so dynamic
   that administrators of the validating clients will not be able to
   follow the modifications.

I don't understand this sentence.

§ 3.1.4.1

  On the other hand, it is
   expected that if effective attacks on either algorithm appeark, they
   will appear for RSA/SHA-1 first.

This needs a citation to be reasonable.  The I-D is not a survey of
the cryptographic literature, and there's no evidence for this claim
in the document.  There's also just about no discussion heretofore in
the document of the key-size/algo strength issues.  I'm perfectly
prepared to support a draft that says, "No, really, SHA-256.  If you
really want to know why, see [ref]."  That's not what this says.  The
same thing goes for the subsequent, "At the time of publication, it is
known that the SHA-1 hash has cryptanalysis issues.  There is work in
progress on addressing these issues."  (Anything starting "it is
known" is automatically suspect, IMO, because I want to know "by
whom".  Cite or remove, I say.)

§4.2.4:

   Because of the algorithm downgrade protection in RFC4035 section 2.2,
   you may not have a key of an algorithm for which you do not have
   signatures.

Is there an extra "not" in one of those parts?  As it reads, you don't
have the key or the signatures, so there's no problem.

§ 4.2.5: "As keys must be renewed periodically".  Earlier text
presents that as but one approach, so this should be changed to "If
keys are to be renewed periodically…"

§ 4.3:  The bulletted list here could be read as being ANDed together,
whereas I'm pretty sure it's OR.  Either altering the introductory
text to say "as long as one of the following conditions is true:" or
else to put an "or" after the second bullet would probably clear that
up.

§4.3.1.1: PROSE

   If we follow this advice, the timing of the replacement of the KSK is
   somewhat critical.  The goal is to remove the compromised KSK as soon
   as the new DS RR is available at the parent.  And also make sure that
   the signature made with a new KSK over the key set with the
   compromised KSK in it expires just after the new DS appears at the
   parent, thus removing the old cruft in one swoop.

"Somewhat critical" scans wrong, like "sort of deadly" or something
like that.  I'd get rid of the "somewhat", since in fact the timing of
replacement is critical to this operation.  Also, the "parent.  And
also" transition should not be a new sentence.  

SUBSTANCE: the timing discussion here suggests the kind of "moment in
time" thinking that is elsewhere in the document exposed as
dangerous.  In fact, you don't want the compromised KSK to expire just
after the new DS appears at the parent, but just after (new DS appears
+ TTL on DS RRset).  That's explicitly made clear in the numbered list
that follows.  I suggest removing the "just".

In the last sentence: Note that this is only a problem when the DNSKEY
and or DS records are used for authentication at the parent," if
you're going to use "and/or", it needs a slash; otherwise it looks
like a typo.  I think "or" works well enough here anyway.

§4.4.2: Who owns the DS?

We have this:

    […] a child zone
   might wish to have a DS published using a message digest algorithm
   not yet understood by the registry, the registry can't count on being
   able to generate the DS record from a raw DNSKEY.  Thus, we recommend
   that registry systems at least support storing DS records.

The basic unstated premise there is that the child zone gets to decide
what the DS record is like.  That is a natural move, because the
DNSKEY record is determined by the child side, and since that's what
the "fundamental data" is, then presumably the RR itself ought to be
decided by the child.

This is a non-trivial premise, however, because the DS RR is _only_
authoritative data on the parent side, and it's therefore data that
belongs properly only to the parent.  In this way, there's a
disanalogy with (for instance) NS records.

It is therefore not unreasonable for a parent operator to refuse to
serve any DS record that it doesn't understand.  The text as it stands
suggests it _is_ unreasonble, and I think it ought to be changed.  The
work that's gone on for RFC 4310bis, in my view, reflects this change
of approach.  Here's suggested new text:

   When designing a registry system one should consider which of the
   DNSKEYs, the corresponding DSes, or both, to store.  On the one
   hand, one might regard the DS as fundamentally derivative of the
   DNSKEY data that originates at the child.  In that case, it is
   reasonable to treat the operator of the child zone as the source
   for the DS record, in much the way parent-side NS records are
   generated; and, for the registry to store a DS record that comes
   from the child.  This has the additional benefit of permitting the
   publication of a DS using a message digest algorithm not yet
   understood by the registry.

   On the other hand, the DS is authoritative data only on the parent
   side of a zone cut.  For this reason, registry policy might be to
   require the submission of DNSKEYs so that the registry can generate
   itself the DS record for which it alone is authoritative.  This has
   the additional benefit that the registry controls the
   transformation of the DNSKEY into the DS, so that any errors in
   this step are solely under the control of the registry operator.

   It may also be useful to store both a DS and corresponding DNSKEY,
   since having them may help during troubleshooting.  Having an
   out-of-band mechanism, such as a registry directory (e.g., Whois),
   to find out which keys are used to generate DS Resource Records for
   specific owners and/or zones may also help with troubleshooting.

   The storage considerations also relate to the design of the
   customer interface and the method by which data is transferred
   between registrant and registry; Will the child zone administrator
   be able to upload DS RRs with unknown hash algorithms or does the
   interface only allow DNSKEYs?  In the registry-registrar model, one
   can use the DNSSEC extensions to the Extensible Provisioning
   Protocol (EPP) [draft-gould-rfc4310bis-07], which allows transfer
   of DS RRs and DNSKEY RRs.

§4.4.5 I'm skipping this because I'm pretty sure Olafur's recent work
on the topic offers a lot of clarification.  If the editors want new
proposed text anyway, please ask & I'll work up some.

§ 5.3.4: to address the Ed note in there, perhaps insert the term
"roughly" before "from"?  

AppxA: The "joyfully signs" bit made me chortle.

Respectfully submitted,

Andrew

-- 
Andrew Sullivan
[e-mail]
Shinkuro, Inc.