Re: Recall: Key rollover Work.

[Andrew Sullivan <[e-mail]>]

On Wed, Jun 28, 2006 at 07:44:18AM +0200, Olaf M. Kolkman wrote:

> I would really appreciate if the working group did the work on  
> technical review. 

Colleagues,

In response to the request above, I either reviewed or started to
review four documents, in order to compare them to
draft-ietf-dnsext-rollover-requirements-02.txt, and determine which
(if any) meet the requirements set out in that document (I call it
"the requirements" below).

The documents in question are these:

draft-ietf-dnsext-trustupdate-threshold-01.txt
draft-ietf-dnsext-trustupdate-timers-02.txt
draft-laurie-dnssec-key-distribution-02.txt
draft-moreau-dnsext-takrem-dns-02.txt

I did not review draft-weiler-dnssec-dlv-01.txt yet, because I did
not initially think that it was a candidate to satisfy the
requirements.  I'm happy to do so, however (is that wanted?).  I
thought to send these comments now anyway, in the (perhaps misguided)
hope that they'll be helpful to others in the context of the
discussion.

I quickly concluded that draft-moreau-dnsext-takrem-dns-02.txt could
not meet requirement 5.2, because it is published with a "no
derivative works" rider, and because there are restrictions on the
type of license under which software based on it could be released. 
I therefore did not read the document, and cannot comment on its
quality.  (I did read the table of contents, and the document looks
like it would be interesting to read.)

I read draft-laurie-dnssec-key-distribution-02.txt.  I think it is a
good draft, and that it is an excellent idea for how to handle the
problem of which keys may be trusted when getting SEPs set up.  It
does not, however, appear to be a general solution for trust anchor
management: it seems to violate requirements 5.3 and 5.11.  Unlike
another reviewer, I do not think there are scaling problems with it. 
I believe it provides a useful mechanism for getting DNSSEC "off the
ground" in the absence of the signing of the root, so I think it
should be pursued, but not as a solution to the problems laid out in
the requirements.

Of the remaining two drafts (to which I'll refer as -threshold and
-timers), I believe either one has the potential to meet the
requirements.  In my opinion, there are some advantages to each.  If
I have to pick just one, I slightly prefer -threshold, just because
no bit assignment is required and because its approach to the problem
feels natural to me.  But I don't put any great stock in that
preference: I could support either of these drafts.

Both of the drafts appear more or less to meet all the requirements. 
In what follows, I discuss ways in which I think one or the other is
slightly weaker in meeting the requirements as they are written.  In
the case of requirements I don't mention at all, both drafts meet the
requirement equally and adequately in my opinion.

The first caveat is that there is an IPR claim against both of drafts. 
The registered claim appears to meet requirement 5.2; but it is not
plain to me, since I was unable to find actual terms of use.

My view is that -timers is slightly less scalable (requirement 5.1)
than is -threshold, because of the way -timers queries, but I think
the additional load is almost certainly too little to be worthy of
consideration.

I have a tiny worry about manual operation (5.6) and -timers.  It
appears to me that the wrong kind of manual operation will result in
the Missing state.  I think this could be addressed in the draft,
however.

I think that all-key compromise could be slightly worse for -threshold
than it is for -timers, in that under a total key compromise,
-threshold devolves to STALE, whereas I've managed to convince myself
that the same case in -timers just puts the zone back into an
unsecured state (I may yet un-convince myself of that.  Clue sticks
are welcome).  This is somewhat related to Thierry Moreau's comment
in
<http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00870.html>;
but my view is ultimately that no protocol is going to save operators
from key mismanagement.  I think both drafts work well in the
presence of good key management regimes.  I do have a worry about
-timers in the case of single key compromise, in that the hold-down
period is at minimum 30 days.  One advantage I see for -threshold in
this case is that the rollover acceptance policy is determined by the
client.  So each of these meets the "unplanned" requirement of
section 5.7 (they both handle planned rolls just fine, as near as I
can tell), but with different potential issues.

A similar set of considerations apply to requirement 5.8.  (I'm
particularly concerned about timeliness in the context of unplanned
events, so that's how I read 5.8.)

I think that -threshold might fail requirement 5.9 in the event of
multiple key compromise or expiry.  This may be a matter of correct
maintenance, though.

While neither document requires a new RR type (5.10), -timers does
need a bit assignment.

Requirements 5.11 itself is slightly confusing to me, because I don't
think there's really any such thing as "replac[ing] an existing Trust
Anchor with another."  It's more exactly a matter of adding one, and
removing another.  Assuming that's what the requirement authors mean
(and I believe it is), I think both drafts meet this.

Because -threshold relies on multiple keys to make up the threshold,
it is entirely possible that in normal operation it would violate
requirement 5.12 (specifically, the "at least one" formulation
therein).  This is true by design, and I think that -threshold's
approach is in keeping with the sentiment behind 5.12 (recovery
should be possible in case of some compromises, but maybe not total
compromise); but -threshold nevertheless cannot meet this requirement
as written.

I believe it is possible to get either -timers or -threshold to
violate requirement 5.13, if you change enough keys fast enough, but
I suspect that would be true of any implementable specification.

Any comments I have on the documents themselves I'll send under
separate heading.

Best regards,
A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[e-mail]>                              M2P 2A8
jabber: [e-mail]                 [phone] x4110

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>