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