Re: [DNSOP] Expiration impending: <draft-jabley-dnssec-trust-anchor-11.txt>

["Paul Hoffman" <[e-mail]>]

On 28 Sep 2015, at 4:59, Joe Abley wrote:

> Hi all,
>
> We don't seem to be getting anywhere with this draft. (Jakob is going 
> to bump it to -12; there have been no real updates apart from the 
> version bump in
>
> I appreciate that the methods described in this document are not 
> universally liked. I have a feeling that we would get more discussion 
> if the question was more open-ended, e.g. how should trust anchors be 
> published?
>
> This document describes existing practice, and provides guidance for 
> people who need to bootstrap a validator using the mechanisms provided 
> by ICANN back in 2009/2010 when the root zone was first published.
>
> Here's a suggestion. If we were to consider publishing this document 
> as-is as a way of describing the current approach, we would at least 
> have a stable reference to the way we do things today. We could always 
> consider other approaches and, once implemented by ICANN, publish a 
> new document that obsoletes or updates this one.
>
> If that's an approach that people could stomach, then I would suggest 
> the next step is to WGLC this document and for those who would like to 
> propose different mechanisms to write them down.

We could do that, but the RFC should probably not be published for at 
least another six months due to terminology / politics / IANAPLAN, so we 
don't need to rush the WG LC either. For example, the draft uses the 
phrase "an IANA function performed by ICANN", to which many folks at 
layer 9 will object until the transition has already happened.

If the WG wants to adopt this draft before the IANA transition is done, 
I would strongly prefer that the document be first adopted before there 
is a WG Last Call. Getting the wording in the document about "this is a 
current implementation" should be done in more than one step. As a 
concrete example, the abstract boldly states "This document describes 
how such trust anchors are published" which should instead be "This 
document describes one way how such trust anchors are published". Even 
the phrase in the abstract "has been cryptographically signed" can be 
misread by the ICANN skeptics as "was signed in the past, but isn't 
currently". There are other examples in the document that should be 
stated more carefully.

Also: how much is this document really needed? Are there operators of 
validating resolvers who are unfamiliar with how to get the trust 
anchor? It is likely that the most common method for getting the DNSSEC 
trust anchor for the DNS is "it came in my distro". If so, then a "how 
it is currently done" document needs to emphasize the positive and 
(maybe very) negative aspects of this practice.

--Paul Hoffman