Re: [DNSOP] Call for Adoption for draft-wessels-edns-key-tag

Matthijs Mekking <> Tue, 01 December 2015 07:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C4DF21A8876 for <>; Mon, 30 Nov 2015 23:49:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.195
X-Spam-Status: No, score=0.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E3uJvgf7dsOU for <>; Mon, 30 Nov 2015 23:49:45 -0800 (PST)
Received: from ( [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D00BB1A8872 for <>; Mon, 30 Nov 2015 23:49:44 -0800 (PST)
Received: from [IPv6:2001:981:19be:1:40a7:9e77:47d:f68d] (unknown [IPv6:2001:981:19be:1:40a7:9e77:47d:f68d]) by (Postfix) with ESMTPSA id D7AD540BF for <>; Tue, 1 Dec 2015 08:49:41 +0100 (CET)
Authentication-Results:; dmarc=none
References: <>
From: Matthijs Mekking <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Tue, 1 Dec 2015 08:49:40 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] Call for Adoption for draft-wessels-edns-key-tag
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: Tue, 01 Dec 2015 07:49:46 -0000


I think this is a nice approach for gaining confidence in a rollover of
a key that acts as a trust anchor. It can even be used to detect
validators that have missed the rollover.

I would however be cautious with using the information as an event
trigger. The draft says

   The goal of these
   options is to signal new trust anchor uptake in client code to allow
   zone administrators to know when it is possible to complete a key
   rollover in a DNSSEC-signed zone.

Since the zone administrator can impossibly know whether all validators
have signalled its trust anchor, you cannot use this information to
speed up a key rollover.

Also, the zone administrator already knows when to complete the key
rollover by calculating the appropriate interval times (ttl,
propagation, etc). This signalling does not add anything to that knowledge.

Then some words about the uniqueness of key tags. The draft already
mentions it briefly, but just within the same zone. Since the queries
will visit various name servers, authoritative for different zones, how
do you deal with such key tag clashes. For example, a validator has the
root key set as a trust anchor, and the root and both have
DNSSEC keys with tag 12345. Does the zone administrator of now
also believe that its key is installed as a trust anchor?

Also, like the draft also mentioned, these queries can be created by
anyone and there is no way of authenticating the validator, so anyone
can signal key tags to give a zone administrator a false sense of
confidence. How could an administrator act on that such that valid
signalling stays useful?

To summarize, I am arguing that perhaps more bits than just the keytag
must be signalled, and that more words should be spend on how to deal
with the malicious key (tag) signalling.

Best regards,

On 28-11-15 13:45, Tim Wicinski wrote:
> This starts a Call for Adoption for draft-wessels-edns-key-tag
> The draft is available here:
> There was unanimous support this during the meeting in Yokohama, so this
> is more of a formality, unless we hear strong negative reaction.
> However, please indicate if you are willing to contribute text, review,
> etc.
> Since there was unanimous support for this draft, I am going with a one
> week Call for Adoption. Please feel free to protest if anyone feels this
> is out of line.
> This call for adoption ends 7 December 2015.
> Thanks,
> tim wicinski
> DNSOP co-chair
> _______________________________________________
> DNSOP mailing list