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

["Joe Abley" <[e-mail]>]

On 28 Sep 2015, at 12:35, Paul Hoffman wrote:

> 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.

I think we have consensus that a good reference for how to retrieve 
trust anchors is a really, really good thing to have long before anybody 
starts coming up with dates for the KSK rollover.

To put that more forcefully, I think it'd be a really bad idea if people 
didn't have solid guidance from the IETF about how things are supposed 
to work well in advance of the KSK actually rolling.

Assuming I'm not alone in that thinking, perhaps we could look at the 
current text and consider whether there's a way to de-politicise it to 
the extent that it does its job and describes current practice.

This doesn't need to be a dnsop document. It could be an AD-sponsored, 
individual submission. But even in that case the IESG would surely (and 
reasonably) expect it to be reviewed here to confirm that it does 
actually document the current state of things.

> 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.

Fully agree that edits to the benefit of clarity, accuracy and the 
avoidance of politics seem entirely worthwhile and sensible.

> 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.

Those who use implementations that follow the guidance in the document 
(e.g. unbound) don't need to care. Those who don't, in my experience, 
tend towards trust on first use. Maybe that's good advice.

There's a companion draft draft-jabley-validator-bootstrap that aims to 
provide this kind of guidance. The goal of 
draft-jabley-dnssec-trust-anchor was to document how the trust anchors 
are published, not how to consume them. I think this is a useful 
separation.


Joe