Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-key-tag-00.txt

Edward Lewis <edward.lewis@icann.org> Thu, 10 December 2015 20:07 UTC

Return-Path: <edward.lewis@icann.org>
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 1E4231B2A1C for <dnsop@ietfa.amsl.com>; Thu, 10 Dec 2015 12:07:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.429
X-Spam-Level:
X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 tWuff9NlYih1 for <dnsop@ietfa.amsl.com>; Thu, 10 Dec 2015 12:07:00 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CAC71B29CB for <dnsop@ietf.org>; Thu, 10 Dec 2015 12:07:00 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 10 Dec 2015 12:06:58 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Thu, 10 Dec 2015 12:06:58 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: IETF DNSOP WG <dnsop@ietf.org>
Thread-Topic: [DNSOP] I-D Action: draft-ietf-dnsop-edns-key-tag-00.txt
Thread-Index: AQHRMsAaeAmRdWaBGUy6z93pjC/sw57FDXWA///L94A=
Date: Thu, 10 Dec 2015 20:06:58 +0000
Message-ID: <D28F42C0.11F3C%edward.lewis@icann.org>
References: <20151209202733.1080.44157.idtracker@ietfa.amsl.com> <CA+nkc8AJD5F2o6hg-UQPFZmr722g2Ld8fh5iH8x80j3W_LFC-g@mail.gmail.com>
In-Reply-To: <CA+nkc8AJD5F2o6hg-UQPFZmr722g2Ld8fh5iH8x80j3W_LFC-g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.8.151023
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.234]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3532604815_2746366"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/p-K42lzo3Uq0on4JKdQn-u3pxE8>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-key-tag-00.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: Thu, 10 Dec 2015 20:07:02 -0000

On 12/10/15, 13:13, "DNSOP on behalf of Bob Harold" <dnsop-bounces@ietf.org
on behalf of rharolde@umich.edu> wrote:

> that information might be useful to the receiver.

This raises a good point to me.  As someone who will be in the position of
making use of such data (if available), what will I be doing with it, what
granularity is needed?

The receiver of this (the trust anchor operator) is not going to be able to
really act on the information in the sense of fixing "broken" applications.
I mean, if an IP address tells me they don't have my latest trust anchor,
I'm not about to get into a conversation (packet exchange) with them to get
them up to date.

I'm never going to be able to see this as 100% adoption either.  Because
once I put a candidate trust anchor up and being to count the 30 days, there
will always be someone "starting life" with RFC 5011.  The first time a 5011
adherent sees the key might be the 29th day I have it out there.  (Whether
or not such a case is "valid" within 5011's model is another matter
entirely.  Perhaps a validator starting life will have to consult some other
way to get to an initial state of security and that other way may already
declare the candidate to be full-fleldged.  Well, then they'll already list
the key tag.  Hmmm.)

I don't know if there's need to aggregate.  EDNS0 is hop-by-hop and I can't
see that trying to fight its nature will give us a benefit that overcomes
the cost of "tunneling" information through the hops.  If a validating IP
address has to go though a forwarder (in a captive network), what trust
anchors it has isn't really useful to the receiver of the option.

My sense is that when I look at the responses, I'll get a sense of how many
IP addresses hitting my servers have the candidate trust anchor and I can
make a decision to roll.  If I just know about the IP addresses that hit me,
I think that's probably sufficient.  (Am I wrong?)