[DNSOP] Configured Trust Anchor vs. DS record

Edward Lewis <edward.lewis@icann.org> Thu, 09 November 2017 14:39 UTC

Return-Path: <edward.lewis@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id EF39C128B51 for <dnsop@ietfa.amsl.com>; Thu, 9 Nov 2017 06:39:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3KjDbFQxh3km for <dnsop@ietfa.amsl.com>; Thu, 9 Nov 2017 06:39:50 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E1C124319 for <dnsop@ietf.org>; Thu, 9 Nov 2017 06:39:50 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org ( by PMBX112-W1-CA-1.pexch112.icann.org ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 9 Nov 2017 06:39:48 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1178.000; Thu, 9 Nov 2017 06:39:48 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: dnsop <dnsop@ietf.org>
Thread-Topic: Configured Trust Anchor vs. DS record
Thread-Index: AQHTWWiXPRp7CRP4/kG/0ZKc0dRV5w==
Date: Thu, 09 Nov 2017 14:39:47 +0000
Message-ID: <5C194845-AB79-47DE-B936-97560D071C5D@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/f.27.0.171010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3593065186_1844476778"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eBM5HhLLjw-T8O1S9bPQ_FPNo0Y>
Subject: [DNSOP] Configured Trust Anchor vs. DS record
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 09 Nov 2017 14:39:52 -0000

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 "two.one/145"

Received data for "three.two.one" signed by "two.one/9342"

What would cause "two.one/9342" to be signed by "one/17" and not by "two.one/145"?  (I think this captures the question of interest.)

1. "two.one/145" is in the MISSING state from STD 69.
2. "two.one/145" was revoked but the validator didn't remove it.
3. "two.one/145" is stale, as the validator is not using STD 69.
4. "two.one" was re-delegated, the previous holder still uses "two.one/145"
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 "two.one"?

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.