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

"Wessels, Duane" <> Wed, 25 November 2015 21:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2E8301B30ED for <>; Wed, 25 Nov 2015 13:53:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G3RBRvvBcDu0 for <>; Wed, 25 Nov 2015 13:53:27 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::261]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 799FE1A8851 for <>; Wed, 25 Nov 2015 13:53:27 -0800 (PST)
Received: by oiww189 with SMTP id w189so3846194oiw.2 for <>; Wed, 25 Nov 2015 13:53:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=CR9MxX6ixY5Mrebrv5n+tWyufCLyB7FIRUxZM7WY+K0=; b=DtoU9eyN3DmcieOLmDJC2uKFdd6hVVZziNCU3ZVqmQTcGpSsrWMuurB/lJ+2/gDpVm D4sshe+e3NmDQYlp7m8fN4yeVso44w0BGoRwQqZLHt6ZzL/7sSU1suuKzb43ubuQybvV QB3nGc9zbtVPYmsxfOCMhcOtVb0wQI+KfTi2yBQfp1RMyrPdXLwuqNe/YRiIsKbAzJDN 1o719glj1qDmoOnpRFGAFHJMGnryBg2/vNVeHCJSqeZnOCNMWXaYBp2oRB5RzfuWXtu9 tzXFwuYd7UyafwttVR24UFLoZaYLP2gXq+2w1QGxWIWr8fuBBplCjOgnV0OKO5d+oR4C DNSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=CR9MxX6ixY5Mrebrv5n+tWyufCLyB7FIRUxZM7WY+K0=; b=X56q32AneHMR2Nf4BHZFk0MbN9EpoOvVOwYiYNWqandD27U5b0+70XWmczMZNVrvdy JtXVKndoIrkTQUmwOJ60XI3FYhP8IMt8c2tPWJ4lgVkdN9bbkAY0gppc4ndELde6Awgj Qq7Cogj2256qrr/Q5TlSOKr6pgLbZWIZN705CezgdgUbdcSxs2CwolRDVrrenm1WGdHL 70paxQPXcobR0FKVd7Q0dVRPEpwrLWAxyrqMltYpHetXduuIoLQt3OAq8CLC5o7NBtWh T/v5EjVjnPP0OObfkwFbA8vfUQUs3901DsZqptan7ilePgw8WJb2F9KwPaqe+KOnni9h 227g==
X-Gm-Message-State: ALoCoQl790EOlzBbpa7SB4dOQtD/okCoklO8AdaJlyQX0JocFHTQdrH1App1BbRu1aBZ5DpwWN+Xf4CbEC4qWQ8KXZy0zX5u5g==
X-Received: by with SMTP id c79mr41715169qkb.44.1448488406814; Wed, 25 Nov 2015 13:53:26 -0800 (PST)
Received: from ( []) by with ESMTPS id s72sm2776896qkl.9.2015. (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 25 Nov 2015 13:53:26 -0800 (PST)
Received: from (brn1wnexchm01 []) by (8.13.8/8.13.8) with ESMTP id tAPLrQMb002923 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 Nov 2015 16:53:26 -0500
Received: from ([::1]) by ([::1]) with mapi id 14.03.0174.001; Wed, 25 Nov 2015 16:53:25 -0500
From: "Wessels, Duane" <>
To: Edward Lewis <>
Thread-Topic: More comments on draft-wessels-edns-key-tag-00
Date: Wed, 25 Nov 2015 21:53:25 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [DNSOP] More comments on draft-wessels-edns-key-tag-00
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Nov 2015 21:53:29 -0000

> On Nov 25, 2015, at 12:17 PM, Edward Lewis <> wrote:
> On 11/25/15, 13:05, "Wessels, Duane" <> wrote:
>> Can you say more about how limited you think it should be?  Never?
> (Probably) as much as possible.  I can't see the benefit of telling a
> third party this.  (First party being the validator/querier, second party
> being the authority of the trust anchor set, third party including the
> upstream.)

Well, the benefit is really for the authoritative.  So the benefit of
telling the third party is that the third party will forward it to the
second party.

>> 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?
> And to the IP addresses for the zone's advertised name servers.

Are you saying that stub clients should communicate directly with 
authority servers?

>> 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?
> Nothing in particular.  I'm not even clear if it's attackers I am worried
> about, it's just general leakage.   I don't see damage in leaking, per se,
> outside of the "if someone knows trust anchor #4 was reverse engineered,
> then the verifier using it is vulnerable."  It's more that I don't see a
> benefit in allowing leakage.
>> Is it okay for a recursive to expose old trust anchors, but not okay for
>> a stub?
> Hmmm, I don't think the two (stub and recursive) are different for this
> option.  (In the sense that EDNS is hop-by-hop and not end-to-end, and the
> only query handler that can make any use of this information is the
> authority.)

Earlier you said that stubs shouldn't send the option because it 
could expose old vulnerable trust anchors.   But now I hear you
say that its no different for stub and recursive.  

If exposing old trust anchors is a problem for stubs why is it not also
a problem for recursives?

My own opinion is that the benefits outweigh the risks.

I sense similarities to the (terrible) advice that you should obfuscate your
"version.bind" string.  Ugh.

>>> (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 was thinking - if a validator is forwarding all traffic to a recursive
> server that is also DNSSEC validating, and there is a conflict because the
> "upstream" is SERVFAIL'ing some data because of, say, the trust anchor not
> right, the "downstream" ought to revert to "+CD" to avoid the buggy
> in-validation.

That would seem to apply regardless of the proposed edns-key-tag option.
FWIW the draft mentions CD in just one place:

   If the client included the DO and Checking Disabled (CD) bits, but
   did not include the edns-key-tag option in the query, the validating
   recursive resolver MAY include the option with its own Key Tag values
   in full.