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

Jakob Schlyter <jakob@kirei.se> Mon, 05 October 2015 13:32 UTC

Return-Path: <jakob@kirei.se>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A141ACD6C for <dnsop@ietfa.amsl.com>; Mon, 5 Oct 2015 06:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.661
X-Spam-Level:
X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwqDO9HvNTWL for <dnsop@ietfa.amsl.com>; Mon, 5 Oct 2015 06:32:16 -0700 (PDT)
Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A809D1ACD3E for <dnsop@ietf.org>; Mon, 5 Oct 2015 06:32:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=y5TM+j6GTBV6pxfLRCBPBd5/P2f1NL7sBJywelryK+I=; b=QoQnhUGtFwfz99YEd9pWUObJ7eM02lRuM6onMCfE7I3nZFTb9CXsUw0hwLJaCduu1rsA8dkQb+nrh F8n9rX3J3NCvA0E+kZgLlNavcRdy/vEM9NRXfiuQi6rcxwXDDtHERZeBfw/nAG1s6Gj5vsD+3e/mrC O65AwNNObChsdFVw=
Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Mon, 5 Oct 2015 15:32:12 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3095\))
From: Jakob Schlyter <jakob@kirei.se>
In-Reply-To: <D1C15986-603E-4932-B551-0497638D9849@vpnc.org>
Date: Mon, 05 Oct 2015 15:32:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <02869F43-87A4-4797-8FD3-276C02DF665D@kirei.se>
References: <20150928114202.823.19868.idtracker@ietfa.amsl.com> <0E4AA958-7740-4602-A3CF-D2E481DBC15E@hopcount.ca> <20150928155325.GA63874@gaon.net> <20150929095301.32c3e6a3@casual> <13F1D87F-1C07-40EB-86B0-564C4109C9B0@virtualized.org> <1973252D-924F-4EF1-A38F-5EC01AD331F6@gmail.com> <FDD04DCC-59C5-41F5-8CAF-1EF31CD65A34@virtualized.org> <63E1E01E-C172-4A0F-B434-F796546BB657@gmail.com> <C4FA9FA6-76E3-4FF3-862B-C5C0DF75C761@kirei.se> <D1C15986-603E-4932-B551-0497638D9849@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.3095)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/KElRI9PIMjdLWDzjMwdq6Cz5ZAw>
Cc: dnsop WG <dnsop@ietf.org>
Subject: Re: [DNSOP] Expiration impending: <draft-jabley-dnssec-trust-anchor-11.txt>
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Oct 2015 13:32:17 -0000

On 5 okt. 2015, at 15:08, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

>> As far as I'm aware, the document does document current practice.
> 
> It does not. It describes a mixture of some of the current practice and some aspirational hopes for how things might be done. Further, it is incomplete in many aspects.

If it is incomplete, we need to fix that.


> The document goes well beyond describing the files, and this is where it fails. Further, the files are not the only way that the trust anchor is published, so the document is fairly incomplete.

Trust anchors may be published in other ways, but IMHO that is out of scope for this document. As far as I know, IANA does not published the trust anchor in other ways.

"This document describes the distribution of the DNSSEC trust anchors
 from IANA.  This document is concerned only with the distribution of
 trust anchors for the root zone, although the data formats and the
 publication and retrieval methods described here can be adapted for
 other uses."


> If it is not up for discussion, then the document should not be progressed in the IETF at all. Instead, the description of the ICANN's publication methodology should be published by ICANN.

The file formats are not up for discussion, as existing implementations depend on them. The description on how to interpret the contents are of course up for discussion. I'm just saying we need to be careful what we change, if we choose to change things that's been in production for over 5 years.


> This WG should instead consider a very different document: how the IETF thinks that the DNSSEC trust anchors should be published in order to help DNS operators. Joe Abley has an expired (?) draft on this topic. A discussion of what ICANN and others should do for publication seems quite relevant to the aims of this WG.

Although I agree with that, I still find it useful to publish this draft as document how things are done today. If the world did not use the published trust anchors as designed, that is (to some extent) failure. Still, it documents (or apparently tries to) the plan as it were back in 2010.


	jakob