Re: [TLS] Enforcing Protocol Invariants
Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 18 November 2018 20:15 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 BD15C12DD85 for <tls@ietfa.amsl.com>; Sun, 18 Nov 2018 12:15:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 Wth5qlsGtxfY for <tls@ietfa.amsl.com>; Sun, 18 Nov 2018 12:15:08 -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 8EB67128CF3 for <tls@ietf.org>; Sun, 18 Nov 2018 12:15:08 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id F404B327102; Sun, 18 Nov 2018 15:15:06 -0500 (EST)
Date: Sun, 18 Nov 2018 15:15:06 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20181118201506.GC4122@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <CAO7N=i0g9d9x5RdF_guKm3GDAxVRHSV+eHffs6kiJm6dWO7tvw@mail.gmail.com> <CANLjSvXD9_u1UDkRkaNc8fnr=iQYKq73c8j9huMEPnH0XzuU0Q@mail.gmail.com> <D880B51B-ECAB-4158-A0EE-8FF67F9247EC@dukhovni.org> <AF08DB30-144B-427E-9B3E-AC90C4B7E7DB@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <AF08DB30-144B-427E-9B3E-AC90C4B7E7DB@akamai.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/se57uV8WzKyASBbVpJtMAunjPHQ>
Subject: Re: [TLS] Enforcing Protocol Invariants
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: Sun, 18 Nov 2018 20:15:11 -0000
On Sun, Nov 18, 2018 at 02:30:53PM +0000, Salz, Rich wrote: > > [ FWIW, TLS is trust-model agnostic, it is the WebPKI that uses the > usual panoply of CAs. ] > > No, it is not agnostic. It does support other trust models -- raw keys, > PGP web-of-trust -- but it's default and primary model from its inception > is X509 and its (so ingrained you might consider it implicit) "trust the > issuer" model. Look at the definitions of certs and CA's and things like > path validation in PKIX and its predecessors, the "trust anchors" which > builds on the chain model -- chained through *issuers* -- in the protocol, > and so on. [ I don't know why you would choose to argue this point, let's not confuse TLS with the CA/B forum WebPKI in browsers. My post was about TLS. My post was emphatically not an attempt to revive the DANE chain discussion here, and was not even about DANE, nobody is looking forward to reopening that discussion here. However, since bashing DNSSEC is a popular sport, I may for the record, now and then post corrections to messages that mischaracterize DNSSEC. ] The X.509 trust-anchors are NOT specified in TLS, and need not be used. Long before DANE, Postfix supported "fingerprint" authentication, especially for email submission clients, which bypassed the WebPKI and never looked at the certificate issuer. Peter Gutmann may apprise you of similar usage in industrial automation. > The "usual panoply of CAs" is the WebPKI instantiation of a trust model, > but do not confuse it with the trust model itself. I have deployed several > instances of the X509/PKI trust model at work, and none of them use a > conventional WebPKI set of anchors. This was explicitly acknowledged and discussed in more detail in the message you're responding to. Yes, PKIX is not always the WebPKI, but in practice it typically is. > If DANE-TLS is to come back, the authors should use a new TLS certificate > type that is perhaps an X509 structure, but whose trust semantics are > defined by DANE. The recent IEEE vehicle cert did similar, and all it took > was a couple of pieces of email. There is simply no need for that. The existing X.509 encapsultion works just fine, and makes it possible to transparently interoperate with both DANE and CA/B forum WebPKI or other PKIX peers. For clients that can do DNSSEC lookups directly and reliably, DANE works in TLS with no friction. With DANE-TA(2) and DANE-EE(3) you get a different trust model, and DANE-TA(2) does use "trust the issuer", but the ultimately trusted issuer is delivered via DNSSEC TLSA records. DANE does not have to "come back". It is in use today, enabling authenticated SMTP to over 337 thousand email domains and growing: http://stats.dnssec-tools.org/#graphs DANE TLS for SMTP is supported by Postfix, Exim, Halon, PowerMTA, Cisco ESA, ... There are also consumer email providers with millions of users that employ DANE in both directions: comcast.net, web.de, gmx.de, freenet.de, ... and more planned. -- Viktor.
- [TLS] Enforcing Protocol Invariants Ryan Carboni
- Re: [TLS] Enforcing Protocol Invariants Salz, Rich
- Re: [TLS] Enforcing Protocol Invariants Ryan Carboni
- Re: [TLS] Enforcing Protocol Invariants Eric Rescorla
- Re: [TLS] Enforcing Protocol Invariants Viktor Dukhovni
- Re: [TLS] Enforcing Protocol Invariants Jim Reid
- [TLS] Enforcing Protocol Invariants Ryan Carboni
- Re: [TLS] Enforcing Protocol Invariants Eric Rescorla
- Re: [TLS] Enforcing Protocol Invariants Dmitry Belyavsky
- Re: [TLS] Enforcing Protocol Invariants Viktor Dukhovni
- Re: [TLS] Enforcing Protocol Invariants Patrick Mevzek
- Re: [TLS] Enforcing Protocol Invariants Ryan Carboni
- Re: [TLS] Enforcing Protocol Invariants Eric Mill
- Re: [TLS] Enforcing Protocol Invariants Eric Rescorla
- Re: [TLS] Enforcing Protocol Invariants Daniel Kahn Gillmor
- Re: [TLS] Enforcing Protocol Invariants Tony Arcieri
- Re: [TLS] Enforcing Protocol Invariants Viktor Dukhovni
- Re: [TLS] Enforcing Protocol Invariants Hubert Kario
- Re: [TLS] Enforcing Protocol Invariants Lanlan Pan
- Re: [TLS] Enforcing Protocol Invariants Viktor Dukhovni
- Re: [TLS] Enforcing Protocol Invariants Salz, Rich
- Re: [TLS] Enforcing Protocol Invariants Viktor Dukhovni
- Re: [TLS] Enforcing Protocol Invariants Salz, Rich
- Re: [TLS] Enforcing Protocol Invariants Christopher Wood
- Re: [TLS] Enforcing Protocol Invariants Viktor Dukhovni
- Re: [TLS] Enforcing Protocol Invariants Hannes Tschofenig