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>
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]
> *Sent:* Monday, December 12, 2016 9:21 AM
> *To:* Patrick McManus <mcmanus@ducksong.com>; Martin Thomson <
> martin.thomson@gmail.com>
> *Cc:* HTTP Working Group <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
> <mcmanus@ducksong.com>]
> *Sent:* 09 December 2016 22:58
> *To:* Martin Thomson <martin.thomson@gmail.com>
> *Cc:* Lucas Pardue <Lucas.Pardue@bbc.co.uk>; HTTP Working Group <
> 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>
> 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
> >
> >
>
>
>
>
>
> ----------------------------
>
> 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.
>
> ---------------------
>