RE: Expectations for TLS session reuse

Ah, I was talking about it from the reuse-of-existing-connection side again, but you’re right – TLS is stricter about session resumption over a new TCP connection.

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Monday, December 12, 2016 2:24 PM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Lucas Pardue <Lucas.Pardue@bbc.co.uk>; Patrick McManus <mcmanus@ducksong.com>; Martin Thomson <martin.thomson@gmail.com>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Expectations for TLS session reuse

Note that the server is required to enforce this:

   A server that implements this extension MUST NOT accept the request
   to resume the session if the server_name extension contains a
   different name.  Instead, it proceeds with a full handshake to
   establish a new session.  When resuming a session, the server MUST
   NOT include a server_name extension in the server hello.

-Ekr


On Mon, Dec 12, 2016 at 9:53 AM, Mike Bishop <Michael.Bishop@microsoft.com<mailto:Michael.Bishop@microsoft.com>> wrote:

The closest to a rule is in the definition for SNI, RFC 6066:  “If the server_name is
   established in the TLS session handshake, the client SHOULD NOT
   attempt to request a different server name at the application layer.”

It’s certainly not an absolute prohibition, but prior to HTTP/2, I’m not aware of any client that violated the SHOULD, and there were servers that enforced that they matched (including ours).  Prior to Server 2016, when we added HTTP/2 support, making a request for a different host than you’d requested in SNI received a 400 response.  I believe Apache had similar behavior.

HTTP/2 explicitly permits this behavior in certain circumstances; that caused many implementations to loosen their requirements.  No RFC for HTTP/1.1 had language contradicting RFC 6066.  I’m not aware of anyone having backported this behavior into their HTTP/1.1 clients, though as you note, nothing stops them from trying.

From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk<mailto:Lucas.Pardue@bbc.co.uk>]
Sent: Monday, December 12, 2016 9:21 AM
To: Patrick McManus <mcmanus@ducksong.com<mailto:mcmanus@ducksong.com>>; Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>>
Cc: HTTP Working Group <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
Subject: RE: Expectations for TLS session reuse

Thanks for all of your responses. My general impression is that the expectations are not 100% clear cut.

Mike has made a good point about the phrasing of my original question (HTTP/1.1 and HTTP/2 in the same breath). In hindsight I could have been a little clearer. RFC 7540 addresses some of the issues under discussion in the most direct and succinct way I have read, compared to the other resources. I do appreciate the difference, however, one of the ways I have considered things here is to look at RFC 7540 section 9 in isolation; it does not seem to depend on any feature of HTTP/2, unless mux is an essential requirement of coalescing. Perhaps I am mistaken on that front. If it were theoretically possible to coalesce HTTP/1.1-over-TLS connections, the lack of mux could mean worse performance, however in my scenario the performance overhead comes from having to make a total 6 TLS handshakes. I appreciate that HTTP/2 cannot apply retroactively to HTTP/1.1, I don’t expect clients to work that way now but want to adjust my expectations to how (or in what way) they may work. Nevertheless,


On 09 December, Mike Bishop wrote:
> HTTP/1.1 doesn’t reuse connections across hostnames.

I tried to find a rule or definition to this effect, it would be helpful if you could link to a concrete example as that would neutralise any argument otherwise.

On 09 December, Patrick McManus wrote:
> I'd like to stress that 7540 not only talks about h2, but it talks about h2 connection reuse across origins. A connection in this parlance is the whole tcp/tls/alpn stack.

> so if you have an existing connection it may get reused for a different origin (subject to the rules in that section) e.g. to coalesce a request for img2 onto an existing connection to img1.. but if no connection is currently present the UA may connect and SNI to img2 and not try and reuse the tls session. Reusing the TLS session for that seems out of the scope of 7540 section 9.

Interesting explanation. So in my previous email I glossed over the fact that the client made a new TCP connection for each and every host. I guess my desire is for a connection in the parlance of tls/alpn, i.e. independent of the transport layer, especially when there is no active transport connection to latch onto. I appreciate there are more complexities, more information to store and lookup when preparing to create a connection, but it sounds like Chrome might already be doing something like this for QUIC. I’ll see if I can find out any more on that topic.

I’d also like to understand if people think that HTTP/1.1 should be frozen out of picking up such development. I’m not against having to use “protocol-next” is it brings benefits, however, that requires my scenario

> nonetheless I think its a reasonable thing to explore as mt referred to.. but in my mind we don't have standards coverage for it that I can think of.

Are you suggesting there should standards coverage developed for this? If so, what would the appropriate format and forum be?

Regards
Lucas


From: Patrick McManus [mailto:mcmanus@ducksong.com]
Sent: 09 December 2016 22:58
To: Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>>
Cc: Lucas Pardue <Lucas.Pardue@bbc.co.uk<mailto:Lucas.Pardue@bbc.co.uk>>; HTTP Working Group <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
Subject: Re: Expectations for TLS session reuse

+1 to both mike and mt's response.

I'd like to stress that 7540 not only talks about h2, but it talks about h2 connection reuse across origins. A connection in this parlance is the whole tcp/tls/alpn stack.

so if you have an existing connection it may get reused for a different origin (subject to the rules in that section) e.g. to coalesce a request for img2 onto an existing connection to img1.. but if no connection is currently present the UA may connect and SNI to img2 and not try and reuse the tls session. Reusing the TLS session for that seems out of the scope of 7540 section 9.
nonetheless I think its a reasonable thing to explore as mt referred to.. but in my mind we don't have standards coverage for it that I can think of.
-Patrick


On Fri, Dec 9, 2016 at 9:19 AM, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote:
For Firefox at least, we key the session cache on the origin.  That
includes a broader definition than the simple scheme-host-port
definition of origin (for instance, we annotate things specially for
private browsing).  Any time this tuple doesn't match we don't even
find the session state.

We have had a few discussions about what it might take to do what you
describe.  It gets interesting when you combine this with 0-RTT.  I
think that we'd like to find a way to do this, but it's not simple.

For now, I think that the only way to guarantee resumption is to start
with the original name.

I think that Google have a hack of some sort in QUIC that lets them do
cross-origin resumption for their properties, but I don't know the
details.

On 9 December 2016 at 02:02, Lucas Pardue <Lucas.Pardue@bbc.co.uk<mailto:Lucas.Pardue@bbc.co.uk>> wrote:
> Hello all,
>
>
>
> I have a query about the expectations for TLS session reuse that apply to
> HTTP user agents. I am bringing the query to this to the working group due
> to the consideration of the connection reuse topic captured in RFC 7540
> Section 9.1.1.
>
>
>
> The background to my question lies in a scenario that we have, where we have
> the set of hosts {example.net<http://example.net>, 1. example.net<http://example.net>, 2. example.net<http://example.net>, 3.
> example.net<http://example.net>, 4. example.net<http://example.net>, 5. example.net<http://example.net>} that all resolve to the same IP
> address. All hosts can be accessed via HTTPS on port 443. The server
> software is configured to support TLS 1.2 only, with TLS session IDs only.
> The entry point into our scenario is example.net<http://example.net>, which provides a
> certificate with a subjectAlternateName that includes example.net<http://example.net> and
> *.example.net<http://example.net>.
>
>
>
> Our test case in this scenario is making a sequence of HTTP/1.1 requests to
> the set of hosts, starting with example.net<http://example.net> and then moving through the
> hosts (in incrementing order). SNI is used and indicates the name of the
> host being requested at that time. We had some ideas on how a user agent
> might approach TLS session reuse in this test case. However, after searching
> across a range of sources, we were unable to find a definitive, simple
> answer.
>
>
>
> The majority of our testing is based on libcurl, and we have a thread on the
> curl-library mailing list that has led to us opening out the question here.
>
>
>
> Our first test round used a client built on libcurl/7.29.0 and NSS/3.19.1.<http://3.19.1.>
> This showed session reuse across the hosts, and the server software (nginx)
> was happy to process the requests.
>
>
>
> Our second test round, used a newer version of libcurl and a variety of SSL
> backends (NSS, OpenSSL, GnuTLS).  This showed no session reuse. Kamil Dudka
> pointed us to this Mozilla bug ticket as a possible cause of the change in
> behaviour.
>
>
>
> Out third test round used a recent version of Firefox. This showed no
> session reuse.
>
>
>
> It would seem the first test round is an anomaly. However, the subsequent
> tests only characterise what those implementations do, not what a TLS client
> could do in terms of session reuse. I guess my final question is, regardless
> of HTTP version, should we have any expectation of session reuse in our
> scenario (client permitting) or is this type of reuse not a “good thing” and
> therefore is not implemented for good reason?
>
>
>
> Regards
>
> Lucas
>
>




----------------------------

http://www.bbc.co.uk

This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------