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

[Viktor Dukhovni <[e-mail]>]

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

> >https://tools.ietf.org/html/rfc5246#page-5
> >
> >                                  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):

    https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-16#section-3.1.1
    https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-5.1

-- 
	Viktor.