RE: Expectations for TLS session reuse

You’re mixing up two things there, though.  RFC 6066 prohibits the server from accepting a TLS session resumption for a different hostname in SNI than was used in the previous session.  RFC 7540 encourages using an existing TLS session for additional hostnames beyond the one in SNI.  6066 discourages this, but doesn’t forbid it.

Now, should TLS be more lax, so that clients could use their resumption context across SNI values?  Perhaps.  RFC 7540 doesn’t say anything about that.  There’s not (quite) a contradiction – just different views on how advisable multiplexing is.

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


So, there appears to be a contradiction between the two RFCs here, and the question is what should be done about that.

  *   On the one hand RFC 6066 Section 3<https://tools.ietf.org/html/rfc6066#section-3> explicitly prohibits servers from allowing cross-origin TLS session reuse when Server Name Indication is in play, and furthermore discourages clients from trying it on:
"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."
"If an application negotiates a server name using an application protocol and then upgrades to TLS, and if a server_name extension is sent, then the extension SHOULD contain the same name that was negotiated in the application protocol. 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."

·        On the other hand RFC 7540 Section 9.1<https://tools.ietf.org/html/rfc7540#section-9.1> actively encourages connection coalescing to limit the number of TCP connections to the same IP address and port:
"A client MAY open multiple connections to the same IP address and TCP port using different Server Name Indication [TLS-EXT<https://tools.ietf.org/html/rfc7540#ref-TLS-EXT>] values or to provide different TLS client certificates but SHOULD avoid creating multiple connections with the same configuration."

and Section 9.1.1<https://tools.ietf.org/html/rfc7540#section-9.1.1> actively encourages connection reuse when making requests to different authorities for which the server is authoritative, effectively overriding the prohibition in RFC 6006 in the sub-case where TLS+SNI is used with HTTP/2:

"Connections that are made to an origin server, either directly or through a tunnel created using the CONNECT method (Section 8.3<https://tools.ietf.org/html/rfc7540#section-8.3>), MAY be reused for requests with multiple different URI authority components. A connection can be reused as long as the origin server is authoritative (Section 10.1<https://tools.ietf.org/html/rfc7540#section-10.1>). For TCP connections without TLS, this depends on the host having resolved to the same IP address.

For "https" resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI. The certificate presented by the server MUST satisfy any checks that the client would perform when forming a new TLS connection for the host in the URI.

An origin server might offer a certificate with multiple "subjectAltName" attributes or names with wildcards, one of which is valid for the authority in the URI. For example, a certificate with a "subjectAltName" of "*.example.com" might permit the use of the same connection for requests to URIs starting with "https://a.example.com/"<https://a.example.com/> and "https://b.example.com/"<https://b.example.com/>."

I suppose the obvious question is whether RFC 6066 should be revised to permit cross-origin TLS session reuse in light of the connection coalescing introduced and encouraged by HTTP/2. It sounds like there could be an appetite to "backport" this liberalisation into HTTP/1.1-land. Of course, the same safeguards around cross-origin certificate validity mentioned in RFC 7540 would need to be spelled out clearly.

For reference, these are the two modes that Lucas and I have considered, and I think they're both potentially relevant in the context of HTTP/1.1. I can imagine a web browser finding both modes useful at different times when using a gang of TCP connections to talk to different domain shards that happen to be sitting on the same IP address and port:

  1.  Requests to different named origins on the same TCP connection after an SNI to one of those origins was included in the TLS client hello.

     *   Having the flexibility to use an established connection to make requests to any (permitted) virtual host on the same server avoids the need to set up a new connection for each one.

  1.  TLS session sharing across different TCP connections to the same IP address and port, each with a different SNI in the client hello.

     *   This avoids the need to negotiate different security context across multiple connections (where permitted), so is more about efficiency gains at connection setup time.

In mode 1 above, a TLS terminator always has the option of forcing a client to establish a new TCP connection if it doesn't want the TLS session to be shared for whatever reason (e.g. to avoid leaking security context between unrelated origins sitting behind a single middlebox). RFC 7540 Section 9.1.2<https://tools.ietf.org/html/rfc7540#section-9.1.2> specifies the 421 (Misdirected request) status code to signal this, and a revised RFC 6066 might need to reference this too. (One could argue that this shouldn't be needed if the server certificate correctly identifies cross-origin opportunities using subjectAltName, but belt and braces is probably no bad thing to allow for bad client behaviour.)

Festive regards,

On 13/12/2016 17:22, Mike Bishop wrote:
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
Sent: Monday, December 12, 2016 2:24 PM
To: Mike Bishop
Cc: Lucas Pardue; Patrick McManus; Martin Thomson; HTTP Working Group
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.

On Mon, Dec 12, 2016 at 9:53 AM, Mike Bishop 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
Sent: Monday, December 12, 2016 9:21 AM
To: Patrick McManus; Martin Thomson
Cc: HTTP Working Group
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?

From: Patrick McManus
Sent: 09 December 2016 22:58
To: Martin Thomson
Cc: Lucas Pardue ; HTTP Working Group
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.

On Fri, Dec 9, 2016 at 9:19 AM, Martin Thomson 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 wrote:
>
> 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?



--

Richard Bradbury | Lead Research Engineer

BBC Research & Development

Centre House, 56 Wood Lane, London  W12 7SB.

T: 0303 040 9672  F: 020 8811 8815