Re: [TLS] Update spec to match current practices for certificate chain order

Viktor Dukhovni <> Mon, 11 May 2015 16:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7D2B81ACDF0 for <>; Mon, 11 May 2015 09:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XRksJrhEzMM2 for <>; Mon, 11 May 2015 09:57:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 812FF1A86E3 for <>; Mon, 11 May 2015 09:57:02 -0700 (PDT)
Received: by (Postfix, from userid 1034) id CD2A1283032; Mon, 11 May 2015 16:57:00 +0000 (UTC)
Date: Mon, 11 May 2015 16:57:00 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [TLS] Update spec to match current practices for certificate chain order
X-Mailman-Version: 2.1.15
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, 11 May 2015 16:57:04 -0000

On Mon, May 11, 2015 at 03:03:25PM +0000, Peter Gutmann wrote:

> >
> >
> >                                  the decisions on how to initiate TLS
> >   handshaking and how to interpret the authentication certificates
> >   exchanged are left to the judgment of the designers and implementors
> >   of protocols that run on top of TLS.
> Oh, I thought that was just marketing fluff rather than a hard-and-fast
> requirement.  If it is a set requirement for the protocol though then it shows
> a major disconnect between the protocol designers and its users, you've got a
> protocol that promises to do cryptographic authentication of the server so
> that developers of apps running on top of it don't have to deal with this, and
> yet in that one sentence it quietly makes it Someone Else's Problem.  So the
> developers of the thousands of vulnerable apps will be assuming that the TLS
> layer [0] will do the checking for them, while the TLS layer can conveniently
> say "well, it's not my problem, and I've got the weasel-words to prove it".

Cynicism is a comfortable posture, but you surely know that different
applications have different ways to verify the peer identity.

There are various alternative name forms SRV-ID, DNS-ID or whatever
the client and server operators bilaterally agree on out of band.
The client may even be using leap-of-trust with pinning to authenticate
the server.

Also, with DANE TLSA certificate usage DANE-EE(3) the name binding
is *outside* the certificate (handled by the TLSA record itself):