Re: Expectations for TLS session reuse

[Martin Thomson <[e-mail]>]

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 <[e-mail]> 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, 1. example.net, 2. example.net, 3.
> example.net, 4. example.net, 5. 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, which provides a
> certificate with a subjectAlternateName that includes example.net and
> *.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 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.
> 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
>
>