Subject: [dnsext] Advancement of RFC 5011 - Call for comments - END 24 August 2012

From: Michael StJohns <[email-masked]>
Date: Sun, 05 Aug 2012 00:20:01 -0400

During IETF week I had discussions with the chairs, area director and various other IESG members on the possibility of advancing RFC5011 to Standard under the new rules described in RFC6410.   My intent is to do this as administrative advancement without the issuance of a new RFC.

The conditions for advancement  (and my comments on those requirements) are:

>(1) There are at least two independent interoperating implementations
>       with widespread deployment and successful operational experience.

RFC5011 is specified as the root key rollover protocol.  Other zones appear have adopted this as their mechanism for updating their trust anchors.

RFC5011 is a hybrid of operational practices  (by the zone owner to signal key changes) and implementations (by the zone owner to sign new keys and revocations, and by the client to automatically update the trust store).  

There appear to be more than two implementations on the client side.  There appears to be sufficient support in zone signing tools for the REVOKE bit.

I have anecdotal evidence (and would appreciate more) that successful operational key rollovers have been made with this protocol.

>   (2) There are no errata against the specification that would cause a
>       new implementation to fail to interoperate with deployed ones.

There are no errata.

>   (3) There are no unused features in the specification that greatly
>       increase implementation complexity.

None identified.

>   (4) If the technology required to implement the specification
>       requires patented or otherwise controlled technology, then the
>       set of implementations must demonstrate at least two independent,
>       separate and successful uses of the licensing process.

The IPR claims are non-specific and do not appear to have affected the implementation of the protocol.

What I want to do is open up a three week period to solicit comments on 5011, implementation experience and operational experience.

For 5011, I'm looking only for substantive comments on the Normative sections of the document - sections 2-5.  

Section 9 does contain down-refs to the DNSSEC extensions, but the IESG members I've talked to don't appear to consider them blocking.

Comments are open until 24 August.  With luck I'll be able to ask the area director to start the IETF last call at that point.

Thanks - Mike

---

From: Chris Thompson <[email-masked]>
Date: 05 Aug 2012 17:50:43 +0100

On Aug 5 2012, Michael StJohns wrote:

>During IETF week I had discussions with the chairs, area director
>and various other IESG members on the possibility of advancing RFC5011
>to Standard under the new rules described in RFC6410.   My intent is to
>do this as administrative advancement without the issuance of a new RFC.
>
>RFC5011 is specified as the root key rollover protocol.

I think that is very considerable stretch. I know of no official
description of putative KSK rollovers for the root zone other
than https://www.iana.org/dnssec/icann-dps.txt section 6.6 and
that does not conform to RFC5011. Specifically, the revoked
KSK is never self-signed, so that (correct) RFC5011 client
implementations will never invalidate it as a trust anchor
(although they may for example warn about its strange absence
from the DNSKEY RRset at the end of the sequence).

>  Other zones appear have adopted this as their mechanism for
>updating their trust anchors.

I know of various zones implementing RFC 5011 rollovers in order
to test RFC 5011 client software, but are there really any that are
using it in the expectation that the world in general will have
a trust anchor for them managed this way?

dlv.isc.org might be one such, as ISC have said that they would
follow RFC5011 if they ever rolled its KSK. But as for the root
zone, this remains a matter of (a different sort of) trust, as
there have not so far been any such rollovers.

>RFC5011 is a hybrid of operational practices (by the zone owner
>to signal key changes) and implementations (by the zone owner to
>sign new keys and revocations, and by the client to automatically
>update the trust store).  
>
>There appear to be more than two implementations on the client side.
>There appears to be sufficient support in zone signing tools for the
>REVOKE bit.
>
>I have anecdotal evidence (and would appreciate more) that successful
>operational key rollovers have been made with this protocol.

I have done a number of tests of BIND's client RFC5011 implementation
("managed-keys") presented with correctly implemented rollovers and
with ones mangled in various ways. I know of only one (slightly subtle)
outstanding bug but a number of infelicities in its ability to let
the operator manage the trust anchor state left after a rollover
that fails in various ways. Still, this is probably not the place
to discuss that.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Michael StJohns <[email-masked]>
Date: Sun, 05 Aug 2012 21:01:43 -0400

At 12:50 PM 8/5/2012, Chris Thompson wrote:
>that does not conform to RFC5011.

I think you're ignoring the other sections where 5011 is mentioned.  6.5 in particular says "
RZ KSK roll-over is scheduled to facilitate automatic updates of
   resolvers' Trust Anchors as described in RFC 5011 [RFC5011]."

I'm aware of the issues with the DPS with respect to 5011 and have had a number of discussions both on and off list to fix the "reality" of how the root zone is signed to bring it into line with 5011 recommendations.  However, there is nothing preventing the root zone from moving to compliance with 5011 recommendations without adversely affecting client views of the root zone trust anchor set in a manner preventing 5011 rollovers.

I stand by my statement - the DPS cites 5011 as the mechanism for automated rollover.

> Specifically, the revoked

The revoke bit only has function if the RRSet is signed by the key with the revoke bit - that's by design.  In the case you describe, the key isn't actually revoked - it's just no longer present in the RRSet, but unless manually removed by a 5011 resolver human owner it will remain in the trust anchor set for the node for that resolver.  As I said, several issues with the DPS have been identified.

>that fails in various ways. Still, this is probably not the place

Why wouldn't this be the place.  Is there a change needed to 5011?  Or is this just a mal-implementation on the client side?  Or something in between.