Re: [DNSOP] More comments on draft-wessels-edns-key-tag-00

"Wessels, Duane" <dwessels@verisign.com> Wed, 25 November 2015 18:05 UTC

Return-Path: <dwessels@verisign.com>
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 403041A8755 for <dnsop@ietfa.amsl.com>; Wed, 25 Nov 2015 10:05:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 SuLcboactWBp for <dnsop@ietfa.amsl.com>; Wed, 25 Nov 2015 10:05:20 -0800 (PST)
Received: from mail-qg0-x261.google.com (mail-qg0-x261.google.com [IPv6:2607:f8b0:400d:c04::261]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55BCE1A8759 for <dnsop@ietf.org>; Wed, 25 Nov 2015 10:05:20 -0800 (PST)
Received: by qgef78 with SMTP id f78so3456644qge.3 for <dnsop@ietf.org>; Wed, 25 Nov 2015 10:05:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:content-id:content-transfer-encoding:mime-version; bh=3Qg2xeFwYGeU9li1BPR/IY3WSakXaAzNo/sYEwYZKPw=; b=x3xBAe1C0+09cj/6/GP2JMrCyfvKRkDP9eWxs2nOK0yRddCpkN/KZgt7aY/yXQcgTo POBJJpVjCGmoifbErd0MlpgBUMNvBO4eiUE7tr3tEJ3/syiu/5LASuLJkwfZXer9nOKT +rPMfFhN1zw2X7g5HAbzpnCjWK0Z99Ueem7Fw3toJM/Pv5d6mg6gnrr650R7PJH35NzN T1SFqf63n2ERT2QUY6N4UcfcoEwnem3ZhTgfUPXBT2YWLlSoYtuAMmpDlMXEPk3GMfG8 O5G0LqZvcokGSaERtByXXwE6PwX7taOQYIEqFCZp7uY2APylMvpuhua0wWu5ZnlsVhuo T7Tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:content-id:content-transfer-encoding :mime-version; bh=3Qg2xeFwYGeU9li1BPR/IY3WSakXaAzNo/sYEwYZKPw=; b=DUykmiTvZEHV6nesfW5UtV/Lq06M80Y4xPbiEhTvbyo0tMdrFMappZToacZYC37qvS NnhJ29loTIzHqeUmnQxh3jhZht/NwFxv7ngmQE0AjB/UwRNCQdDlYsuhhAATaWvPKdB8 WYpfoAwsyONVYPR3smztJSHR4BxQWXeg5YPkmlW1sPweA7d7i+cS5MTMF9oPhkc3sdnB Ysl/diao3s7qtZ52OXRc6CtHAvCeuBBEJu9+P1ztu6PICRFZs5/BU2OJmewTPUQZuEa3 KTIPVKnhaioqPzT67QwXWypIfwJ8eChzglgNBZElQ7hgTOiF6t75VOBCInIWHC1O7SgV yggQ==
X-Gm-Message-State: ALoCoQnGAYB9RRvkEfmasCiB2JzGPuBAtb/W080zmyuSM1y2WLmZV2Irl4GTFxjtOXBU2dzkZNi+WnvtSg9PPnB1i9C4m4X6MA==
X-Received: by 10.55.81.3 with SMTP id f3mr29598559qkb.35.1448474719378; Wed, 25 Nov 2015 10:05:19 -0800 (PST)
Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id f126sm2793247qkb.8.2015.11.25.10.05.19 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 25 Nov 2015 10:05:19 -0800 (PST)
X-Relaying-Domain: verisign.com
Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id tAPI5IGx008677 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 Nov 2015 13:05:19 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 25 Nov 2015 13:05:18 -0500
From: "Wessels, Duane" <dwessels@verisign.com>
To: Edward Lewis <edward.lewis@icann.org>
Thread-Topic: More comments on draft-wessels-edns-key-tag-00
Thread-Index: AQHRJv6QbwAYXu6nOU+ons+2uTDEGZ6tIncAgAA7DAA=
Date: Wed, 25 Nov 2015 18:05:17 +0000
Message-ID: <6B70A96A-9E75-465F-9A91-0C1A656F2F4E@verisign.com>
References: <D279FE55.117EB%edward.lewis@icann.org> <CD88ACBF-9E78-4D9D-920B-381694059BDA@verisign.com> <D27B2BCC.11857%edward.lewis@icann.org>
In-Reply-To: <D27B2BCC.11857%edward.lewis@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6286E2A136394146B74A9C3A5FB3BC1D@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/UGFhzcc3nG6_NAVVhly3wtfshHQ>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] More comments on draft-wessels-edns-key-tag-00
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: Wed, 25 Nov 2015 18:05:22 -0000

> On Nov 25, 2015, at 6:33 AM, Edward Lewis <edward.lewis@icann.org> wrote:
> 
> In an effort to simplify and streamline this (for reasons I'll include
> later), what about telling a querier to only send this option when it is
> sending a query to an IP address that is authoritative for the DNSKEY set?

For the recursive-to-authoritative case that is exactly what I had in mind.


> 
> What I'm trying to rule
> out are "stubs" that are sending queries to "upstream" validators or
> forwarders.
> 
> The reason for this is to limit the times a stub exposes the trust anchors
> it has (in case one is known to be exploitable)

Can you say more about how limited you think it should be?  Never?

In what I'm proposing the stub also would send the option only for DNSKEY queries
and only for trust anchor zones (i.e. root).  Is that limited enough?

Do you have particular concerns about who knows about the stub's trust anchors?  
Are you thinking of on-path attackers or the recursive operator or something else?

Is it okay for a recursive to expose old trust anchors, but not okay for a stub?


> and to avoid having to
> come up with rules for union-ing the possible lists of key tags.

I actually like the suggestion I heard from someone (sorry, can't remember
exactly who right now) that instead of intersection or union, the recursive
could just forward a second instance of the option.

> Or, to
> ask another toss up - is there benefit in telling the upstream what trust
> anchors are held?  

I'd say there is a benefit to the zone operator in knowing what trust anchors
are in use by stubs.

> (If there's a conflict between the two (which could
> also be sever clock skew), use 'CD' in queries.)

Sorry I didn't follow that.


> I'm not sure there's a
> benefit telling anyone other than the authority for the trust anchors
> about the set held.
> 
> Now what I am trying to imagine is how the receiver of the option reacts.
> I don't know that I'd recommend any active reaction - like trying to
> inform the querier that their set of tags is out of date.  I have the
> sense that there might be a benefit within a small use case but trying to
> do that would proliferate corner cases as well as work against the loose
> coupling that allows DNS to work at scale.

I am fully against any active reaction.  The edns-key-tag option should
not affect the response in any way, nor cause any "extra" responses.


> 
> I imagine I'd look at packet traces to see what is being sent in, counting
> IP addresses with/by tags of interest.  I.e., out of band (to port 53)
> massaging of the data and reacting to it.  While I realize that during a
> key roll there will always be late comers, having a gauge of how many are
> ready for new signatures is helpful to the roll process.

Yes.


> 
> The response - what would be in it?  Should it be empty?  Should it
> include a set of tags (but what set of tags?). I ask the last because the
> authoritative server would be configured or deduce the set of tags it sees
> which might not agree with what a RFC 5011 validator may have picked up.
> (I.e., keys in the AddPend state are trust anchors in the server, not
> mature enough to be trusted in the client.)  Should it be the set of
> intended trust anchors or the set of what is thought a 5011 validator
> (there that focus goes again) would think the tags should be?

Forgive me for saying, but it sounds to me like you might've misunderstood
a little about what I proposed.  I'm saying the edns-key-tag option rides
along with a DNSKEY query.  So the response is a normal DNSKEY response.

The draft currently says:

  A responder MUST NOT include the edns-key-tag option in any DNS response.

So what I've proposed is one-way, passive data collection only.  Note I modeled this
after RFC 6975, which works the same way.

DW