Re: [DNSOP] Configured Trust Anchor vs. DS record

Petr Špaček <> Thu, 09 November 2017 14:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4704312EC9C for <>; Thu, 9 Nov 2017 06:48:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0qplyKPxSqXP for <>; Thu, 9 Nov 2017 06:48:30 -0800 (PST)
Received: from ( [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4DA47126CF9 for <>; Thu, 9 Nov 2017 06:48:29 -0800 (PST)
Received: from [IPv6:2001:1488:fffe:6:2814:1dff:feea:faf7] (unknown [IPv6:2001:1488:fffe:6:2814:1dff:feea:faf7]) by (Postfix) with ESMTPSA id CF04C641E0 for <>; Thu, 9 Nov 2017 15:48:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1510238906; bh=suqnqTCeaVlynUWt8tkP3z0poDy0dx5hKQZq7nMF1oE=; h=To:From:Date; b=I/JZdKz11FfyofwkPMrCq7HKbHCXuCzWTmSNOefkBn5BF4W0TK+3dGoUIrD6a8MJ+ XHawXR+rugqMXDHdd7I0IfvaHqL38N304LkepLR2UPFe5OeTsDvYvBOZGDsmPbgAvE tFmcPH3aUh7GnNK2FiEQbZF31upFaUtLD/rb4QAY=
References: <>
From: Petr Špaček <>
Organization: CZ.NIC
Message-ID: <>
Date: Thu, 09 Nov 2017 15:48:26 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [DNSOP] Configured Trust Anchor vs. DS record
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Nov 2017 14:48:32 -0000

On 9.11.2017 15:39, Edward Lewis wrote:
> To set up the problem to solve.  Asking for points that are missed.
> (Purposefully omitting the trailing dot, not talking about 'root' because that could get confusing.)
> Trust anchor for "one/17" (i.e., key_id=17)
> Trust anchor for ""
> Received data for "" signed by ""
> What would cause "" to be signed by "one/17" and not by ""?  (I think this captures the question of interest.)
> 1. "" is in the MISSING state from STD 69.
> 2. "" was revoked but the validator didn't remove it.
> 3. "" is stale, as the validator is not using STD 69.
> 4. "" was re-delegated, the previous holder still uses ""
> 5. (open for more scenarios of "why")
> What should the validator do with the response?
> For cases 1,2,3, the chain ought to be accepted.
> For case 4, although the appropriate DNS response (according to the DNS protocol) was received, the application calling it might not want to take action based on the response (action such as open a connection and/or flow data).
> Is there a way, within the DNS, to differentiate amongst the reasons why the response is signed up to "one" and not ""?
> Is there a way the application can tell?
> With DANE as "an application" in mind:  When it comes to DANE, what bothers me is this, in "DNS-Based Authentication for TLS", the section "The Certificate Usage Field" (that is RFC 6698, section 2.1.1), for value "3 -- Certificate usage 3".  For that value, this is stated: "PKIX validation is not tested for certificate usage 3".  My reading of this is that the "problem" with PKIX certificate authorities has just been shifted over to DNS hosting services (in this case for "one"), concerns about the DNS hoster are on par with concerns regarding the certificate authorities.  (In essence, either could re-delegate a name.)  (Yes, this is a tangential off-shoot, anticipating questions about how DANE plays with this.)  In essence, usage 3 removes the benefit of pinning, which the application could use to detect a re-delegation.

Nice write-up Edward! You have nicely summarized why Mark and me agree
that validator should use longest suffix match when selecting TA to
validate data.

Things might get even more complicated when negative trust anchors are
configured, bleh. Let me repeat that I very much prefer longest suffix
match because it is predictable, easy to understand, and thus more
secure than "use any".

(And again, this is relevant only to people who bothered to configure TA
for domain different than root, i.e. largely irrelevant for vast
majority of users.)

Petr Špaček  @  CZ.NIC