- From: Richard Bradbury <richard.bradbury@rd.bbc.co.uk>
- Date: Wed, 21 Dec 2016 12:50:49 +0000
- 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>
- Message-ID: <97158afb-d80a-443c-b59a-209ffe3d34d9@rd.bbc.co.uk>
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/" 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:
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.
2. 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
Received on Wednesday, 21 December 2016 12:51:29 UTC