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

From: "Joe Abley" <[email-masked]>
Date: Mon, 28 Sep 2015 07:59:00 -0400

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.

Chair-people, can we do that?

Joe

Forwarded message:

> From: IETF Secretariat <[email-masked]>
> To: Guy Bailey <[email-masked]>, Jakob Schlyter 
> <[email-masked]>, Joe Abley <[email-masked]>
> Subject: Expiration impending: 
> <draft-jabley-dnssec-trust-anchor-11.txt>
> Date: Mon, 28 Sep 2015 04:42:02 -0700
>
> The following draft will expire soon:
>
> Name:     draft-jabley-dnssec-trust-anchor
> Title:    DNSSEC Trust Anchor Publication for the Root Zone
> State:    I-D Exists
> Expires:  2015-10-08 (in 1 week, 2 days)
>

---

From: Shane Kerr <[email-masked]>
Date: Mon, 28 Sep 2015 12:15:09 +0000

Joe,

On Mon, 28 Sep 2015 07:59:00 -0400

> propose different mechanisms to write them down.

Given that this is supposed to turn into an informational RFC, and it
provides information about how the IANA currently publishes trust
anchors, I fully support it going forward as is.

Cheers,

--
Shane

---

From: Andras Salamon <[email-masked]>
Date: Mon, 28 Sep 2015 16:53:25 +0100

>by ICANN back in 2009/2010 when the root zone was first published.

Preempting a WGLC, I support the document.  It states its aim of
documenting existing practices, and it does so clearly.

Nit in draft-jabley-dnssec-trust-anchor-12: p.2 complimentary -> complementary.

-- Andras Salamon                   [email-masked]

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 28 Sep 2015 09:35:39 -0700

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
>
> 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?
>
> consider other approaches and, once implemented by ICANN, publish a 
> new document that obsoletes or updates this one.
>

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

---

From: "Joe Abley" <[email-masked]>
Date: Mon, 28 Sep 2015 13:02:48 -0400

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

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

> 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

---

From: Shane Kerr <[email-masked]>
Date: Tue, 29 Sep 2015 09:53:01 +0000

All,

On Mon, 28 Sep 2015 16:53:25 +0100

> documenting existing practices, and it does so clearly.

I agree completely. I am actually confused as to why it is not already
an RFC.

Cheers,

--
Shane

---

From: David Conrad <[email-masked]>
Date: Tue, 29 Sep 2015 11:21:03 -0700

> I agree completely. I am actually confused as to why it is not already

+1

Regards,
-drc