Re: Expectations for TLS session reuse

[Martin Thomson <[e-mail]>]

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 <[e-mail]> 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 [mailto:[e-mail]]
> Sent: Wednesday, December 21, 2016 4:51 AM
> To: [e-mail]
> Cc: Eric Rescorla <[e-mail]>; Lucas Pardue <[e-mail]>;
> Patrick McManus <[e-mail]>; Martin Thomson
> <[e-mail]>; Mike Bishop <[e-mail]>
>
>
> 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