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.