Re: Expectations for TLS session reuse

Thanks both for your helpful clarifications. I feel I'm edging gradually 
towards a complete understanding. Re-reading the specifications in the 
light of your comments made me question the distinction between the 
various terms. Is the following a reasonable summary?

  * *TLS session resumption:* using a previously negotiated security
    context on a new transport connection to the same (or to a
    different) IP address and port.
      o Valid for all application protocols sitting on top of TLS.
      o Security contexts can be securely shared between servers on
        different IP addresses and/or ports to support more complex
        distributed Use Cases.
      o Servers implementing SNI only allow this if the hostname is the
        same as in the handshake that originally negotiated the security
        context [RFC 6066 Section 3].
      o Relaxing this restriction could be tricky because of some fiddly
        edge cases (see Martin Thomson's remarks).
      o In the case where the IP address and port are the same, and the
        same server certificate is presented, it's a lot simpler.
      o If I attempt to do establish a TLS session on a new connection
        in parallel with an existing connection (as opposed to serially)
        is that still called session resumption? Is that effectively one
        loigcal TLS session spanning multiple connections, or multiple
        sessions with a common security context?
  * *HTTP connection coalescing:* making requests to different virtual
    hosts over the same transport connection and (when TLS is in use)
    security context.
      o Actively encouraged for HTTP/2 by RFC 7540 Section 9.1.1.
      o Only allowed if the server certificate indicates the equivalence
        of the hostnames via subjectAltName, and the TLS server end is
        willing for the security context to be shared between those
        virtual hosts.
      o A repeat reading of RFC 6066 Section 3 leads me to believe that
        there is actually no restriction on doing this. I think I am
        free to quote a completely different virtual hostname from the
        SNI when I make an HTTP request, even in HTTP/1.1. And the
        server should (in theory) be happy if I meet the criteria in the
        above bullet. In other words, the position is the same for
        HTTP/1.1 as it is for HTTP/2 and there is actually no
        contradiction between RFC 6066 and RFC 7540. Great!
  * *TLS session reuse:* Is this the same as session resumption? Or more
    like connection coalescing? Or a third, subtly different, thing? Or
    just a confusing term I shouldn't be using at all?

For the original Use Case articulated by Lucas at the start of the 
thread, where the destination IP address and port are the same, 
connection coalescing would be my first choice, even for HTTP/1.1 (since 
the requests to the different virtual hosts are serialised and 
multiplexing therefore offers no additional benefit). TLS session 
resumption would be my second choice: there's the additional cost of 
opening up multiple connections in parallel, but at least I don't need 
to waste time negotiating a new security context for each one.

Both options rely on certain behaviour being supported at both the 
client and the server ends, and we'd need to do some comprehensive 
testing to establish the current state of play with common user agents 
and web servers. Our experiments to date aren't very positive. The 
purpose of this thread was simply to confirm whether these behaviours 
are permitted at all by the specifications. If they are, then we can 
work towards more comprehensive client and server implementations.

Or, as Patrick McManus suggests, we could just turn to HTTP/2 and QUIC 
where these features are more readily available because they don't need 
to be retrofitted.

Cheers,


On 21/12/2016 22:52, Martin Thomson wrote:
> Mike has it right.  If we are going to allow resumption across
> "equivalent" names, there are a bunch of concerns to address.  The
> most significant being how the SNI is used for routing and certificate
> selection.  What happens if you get a different endpoint or
> certificate?  We need a clear set of expectations about how resumption
> is expected to work.
>
> Now, resumption currently does not require - or allow - the server to
> re-authenticate, but it gets hairy if you do allow it.  For instance,
> if you get a different certificate that doesn't include the original
> name in its cert, but the server happily resumes, is it the same
> server as before?  What if you just sent it 0-RTT data for that
> original name. Did you just send some information to the wrong server?
>   Do you accept the responses or do you pretend it never happened?
>
> I think that what we need here is for someone to clearly articulate
> what the model is and what is possible within that model.  We don't
> have that right now and I think we're struggling to reach conclusions
> because we each have different expectations.
>
>
> On 22 December 2016 at 09:38, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
>> 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
>> Sent: Wednesday, December 21, 2016 4:51 AM
>> To: ietf-http-wg@w3.org
>> Cc: Eric Rescorla; Lucas Pardue; Patrick McManus; Martin Thomson; Mike Bishop
>> 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 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 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] values or to provide
>> different TLS client certificates but SHOULD avoid creating multiple
>> connections with the same configuration."
>>
>> and 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), 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). 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/" and "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:
>>
>> 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.
>>
>> 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
>> 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, 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?

-- 
Richard Bradbury | Lead Research Engineer
BBC Research & Development
Centre House, 56 Wood Lane, London  W12 7SB.
T: 0303 040 9672  F: 020 8811 8815