Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics
Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 05 November 2018 16:52 UTC
Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B89130E3B for <tls@ietfa.amsl.com>; Mon, 5 Nov 2018 08:52:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84VcG10_8rC3 for <tls@ietfa.amsl.com>; Mon, 5 Nov 2018 08:52:17 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41700130E97 for <tls@ietf.org>; Mon, 5 Nov 2018 08:52:17 -0800 (PST)
Received: from [10.200.18.148] (unknown [38.27.161.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 720AC60ADB for <tls@ietf.org>; 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 <ietf-dane@dukhovni.org>
In-Reply-To: <1450B335-5F7D-43A6-8BC6-181DFE1865C9@akamai.com>
Date: Mon, 05 Nov 2018 10:33:12 -0500
Content-Transfer-Encoding: quoted-printable
Reply-To: "<tls@ietf.org>" <tls@ietf.org>
Message-Id: <A9A21E08-406C-49BA-AA95-C6109390C5A5@dukhovni.org>
References: <20181105130157.GF54966@kduck.kaduk.org> <2714F93F-3658-4E2E-8390-284C6D401447@dukhovni.org> <1450B335-5F7D-43A6-8BC6-181DFE1865C9@akamai.com>
To: "<tls@ietf.org>" <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/HwtJ8WuU99aVMt8luVINNvadt9o>
Subject: Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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 <rsalz@akamai.com> 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). -- Viktor. -- Viktor.
- [TLS] some thoughts on dnssec-chain-extension, pi… Benjamin Kaduk
- Re: [TLS] some thoughts on dnssec-chain-extension… Viktor Dukhovni
- Re: [TLS] some thoughts on dnssec-chain-extension… Salz, Rich
- Re: [TLS] some thoughts on dnssec-chain-extension… Benjamin Kaduk
- Re: [TLS] some thoughts on dnssec-chain-extension… Viktor Dukhovni
- Re: [TLS] some thoughts on dnssec-chain-extension… Nico Williams
- Re: [TLS] some thoughts on dnssec-chain-extension… Viktor Dukhovni
- Re: [TLS] some thoughts on dnssec-chain-extension… Paul Wouters
- Re: [TLS] some thoughts on dnssec-chain-extension… Benjamin Kaduk
- Re: [TLS] some thoughts on dnssec-chain-extension… Paul Wouters
- Re: [TLS] some thoughts on dnssec-chain-extension… Viktor Dukhovni
- Re: [TLS] some thoughts on dnssec-chain-extension… Benjamin Kaduk
- Re: [TLS] some thoughts on dnssec-chain-extension… Benjamin Kaduk
- Re: [TLS] some thoughts on dnssec-chain-extension… Tim Wicinski
- Re: [TLS] some thoughts on dnssec-chain-extension… Viktor Dukhovni
- Re: [TLS] some thoughts on dnssec-chain-extension… Nico Williams
- Re: [TLS] some thoughts on dnssec-chain-extension… Paul Wouters
- Re: [TLS] some thoughts on dnssec-chain-extension… Paul Wouters