RE: Expectations for TLS session reuse

In theory, Richard is correct – “verif[y] that the communicating server’s identity matches the target URI’s authority component” could be considered satisfied if the cert were valid for the target name, even if it’s not the name the connection was originally opened to.

However, I don’t know of any HTTP/1.1 clients that actually implement it that way, and as I said before, I know of HTTP/1.1 servers that will refuse a request in that circumstance.  So as a practical matter, Patrick is correct too.

From: Patrick McManus [mailto:mcmanus@ducksong.com]
Sent: Thursday, December 22, 2016 7:39 AM
To: Richard Bradbury <richard.bradbury@rd.bbc.co.uk>
Cc: Martin Thomson <martin.thomson@gmail.com>; Mike Bishop <Michael.Bishop@microsoft.com>; ietf-http-wg@w3.org; Eric Rescorla <ekr@rtfm.com>; Lucas Pardue <Lucas.Pardue@bbc.co.uk>; Patrick McManus <mcmanus@ducksong.com>
Subject: Re: Expectations for TLS session reuse


On Thu, Dec 22, 2016 at 7:25 AM, Richard Bradbury <richard.bradbury@rd.bbc.co.uk<mailto:richard.bradbury@rd.bbc.co.uk>> wrote:
the position is the same for HTTP/1.1 as it is for HTTP/2

I don't think this is true. H1 is governed by 7230 section 9.. in practice it is a connection per origin:

 The "https" scheme (Section 2.7.2<https://tools.ietf.org/html/rfc7230#section-2.7.2>) is intended to prevent (or at

   least reveal) many of these potential attacks on establishing

   authority, provided that the negotiated TLS connection is secured and

   the client properly verifies that the communicating server's identity

   matches the target URI's authority component (see [RFC2818<https://tools.ietf.org/html/rfc2818>]).

whereas H2 loosens that a little bit for coalescing in 7540.