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

From: Peter Gutmann <[email-masked]>
Date: Mon, 11 May 2015 15:03:25 +0000

Martin Rex <[email-masked]> writes:

>As previously mentioned, all TLS specifications up to and including TLSv1.2
>have been extremely clear that the name contained in the certifcates is a
>matter of the protocols & software layers on top of TLS, and none of TLS
>business:
>
>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".

Peter.

[0] There's probably a better term to use here than Transport Layer Security
    layer.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 11 May 2015 16:57:00 +0000

> 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.