Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

Viktor Dukhovni <> Mon, 05 November 2018 16:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D6B89130E3B for <>; Mon, 5 Nov 2018 08:52:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 84VcG10_8rC3 for <>; Mon, 5 Nov 2018 08:52:17 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 41700130E97 for <>; Mon, 5 Nov 2018 08:52:17 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 720AC60ADB for <>; Mon, 5 Nov 2018 11:52:16 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Mon, 05 Nov 2018 10:33:12 -0500
Content-Transfer-Encoding: quoted-printable
Reply-To: "<>" <>
Message-Id: <>
References: <> <> <>
To: "<>" <>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <>
Subject: Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Nov 2018 16:52:27 -0000

[ I hope the below is short enough...]

> On Nov 5, 2018, at 9:37 AM, Salz, Rich <> wrote:
> Is it fair to describe the draft as enabling a trust model based on DNSSEC, rather than the default X.509 hierarchy and trust store which is implemented by default?
> Please try very hard to keep the answer brief.

The original (-07) draft only does the job for applications that
go all in on DANE and statically skip the WebPKI.

What we're trying to do is to make DANE meaningfully available
also to existing applications where the WebPKI still rules the
roost, and where clients can only determine which servers support
DANE "opportunistically", but for that to be useful, the signal
needs some downgrade resistance.

The ultimate goal is to be able to use DANE either instead of,
or in combination with the WebPKI.  Which it is depends on the
DANE certificate usages that the application supports and server
publishes.  We're not trying to kill the WebPKI, rather we want
the *option* to use DANE when client and server opt-in.

Finally, of course, the reason for the extension is last-mile
issues with DNSSEC in captive portals and behind DNS-challenged
home routers, plus a bit of latency concern (that may be overblown,
but still seems an issue for some).