Subject: Expectations for TLS session reuse

From: Lucas Pardue <[email-masked]>
Date: Fri, 9 Dec 2016 12:02:51 +0000

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<https://tools.ietf.org/html/rfc7540#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<https://curl.haxx.se/mail/lib-2016-11/0179.html> 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<https://bugzilla.mozilla.org/show_bug.cgi?id=1202264> 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

---

From: Mike Bishop <[email-masked]>
Date: Fri, 9 Dec 2016 18:08:38 +0000

You point to a section in the HTTP/2 RFC, but say that you're making HTTP/1.1 requests.  HTTP/1.1 doesn't reuse connections across hostnames.

As for TLS, the TLS client presumably does resumption based solely on hostname - the TLS protocol doesn't know anything about IP addresses, just endpoints with credentials.

From: Lucas Pardue [mailto:[email-masked]]
Sent: Friday, December 9, 2016 4:03 AM
To: HTTP Working Group <[email-masked]>
Subject: Expectations for TLS session reuse

Hello all,

Regards
Lucas

---

From: Martin Thomson <[email-masked]>
Date: Fri, 9 Dec 2016 09:19:40 -1000

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 <[email-masked]> 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.
>
>
>
> 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
>
>

---

From: Patrick McManus <[email-masked]>
Date: Fri, 9 Dec 2016 12:57:50 -1000

+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

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 12 Dec 2016 17:21:09 +0000

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:[email-masked]]
Sent: 09 December 2016 22:58
To: Martin Thomson <[email-masked]>
Cc: Lucas Pardue <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: Expectations for TLS session reuse

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 <[email-masked]<mailto:[email-masked]>> wrote:

On 9 December 2016 at 02:02, Lucas Pardue <[email-masked]<mailto:[email-masked]>> wrote:
> 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
> 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>.
>
>
>
> the set of hosts, starting with example.net<http://example.net> and then moving through the
> Our first test round used a client built on libcurl/7.29.0 and NSS/3.19.1.<http://3.19.1.>

----------------------------

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.

---------------------

---

From: Mike Bishop <[email-masked]>
Date: Mon, 12 Dec 2016 17:53:55 +0000

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:[email-masked]]
Sent: Monday, December 12, 2016 9:21 AM
To: Patrick McManus <[email-masked]>; Martin Thomson <[email-masked]>
Cc: HTTP Working Group <[email-masked]>
Subject: RE: Expectations for TLS session reuse

Regards
Lucas

From: Patrick McManus [mailto:[email-masked]]
Sent: 09 December 2016 22:58
To: Martin Thomson <[email-masked]<mailto:[email-masked]>>
Cc: Lucas Pardue <[email-masked]<mailto:[email-masked]>>; HTTP Working Group <[email-masked]<mailto:[email-masked]>>
Subject: Re: Expectations for TLS session reuse

http://www.bbc.co.uk

---------------------

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Dec 2016 14:23:44 -0800

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 <[email-masked]>
wrote:

> 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:[email-masked]]
> *Sent:* Monday, December 12, 2016 9:21 AM
> *To:* Patrick McManus <[email-masked]>; Martin Thomson <
> [email-masked]>
> *Cc:* HTTP Working Group <[email-masked]>
> *Subject:* RE: Expectations for TLS session reuse
>
>
>
> 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,
>
>
>
>
>
> 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.
>
>
>
> > 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.
>
>
>
> 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:[email-masked]
> <[email-masked]>]
> *Sent:* 09 December 2016 22:58
> *To:* Martin Thomson <[email-masked]>
> *Cc:* Lucas Pardue <[email-masked]>; HTTP Working Group <
> [email-masked]>
> *Subject:* Re: Expectations for TLS session reuse
>
>
>
> 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.
>
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.

---

From: Mike Bishop <[email-masked]>
Date: Tue, 13 Dec 2016 17:22:08 +0000

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 [mailto:[email-masked]]
Sent: Monday, December 12, 2016 2:24 PM
To: Mike Bishop <[email-masked]>
Cc: Lucas Pardue <[email-masked]>; Patrick McManus <[email-masked]>; Martin Thomson <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: Expectations for TLS session reuse

-Ekr

On Mon, Dec 12, 2016 at 9:53 AM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:

From: Lucas Pardue [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, December 12, 2016 9:21 AM
To: Patrick McManus <[email-masked]<mailto:[email-masked]>>; Martin Thomson <[email-masked]<mailto:[email-masked]>>
Cc: HTTP Working Group <[email-masked]<mailto:[email-masked]>>
Subject: RE: Expectations for TLS session reuse

Regards
Lucas

http://www.bbc.co.uk

---------------------

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 13 Dec 2016 18:01:05 +0000

Eric, thanks for highlighting that paragraph. It’s a pretty cast-iron definition and I think eliminates any uncertainty of doubt about what the server must do in my scenario. The clients under test were compliant (except for the buggy version that is now fixed), unfortunately, the server I used in the tests (nginx) did not appear to enforce the expected behaviour. If I am able to find the time, I would like to test against some other server implementations.

I am curious as to the origination (i.e. the requirement) of the quoted paragraph in RFC 6066. I see that older versions (RFC 3546, RFC 4366) did not contain any definition of how to handle session reuse and SNI. Was it added in RFC 6066 in response to a security concern?

Regards
Lucas

From: Mike Bishop [mailto:[email-masked]]
Sent: 13 December 2016 17:22
To: Eric Rescorla <[email-masked]>
Cc: Lucas Pardue <[email-masked]>; Patrick McManus <[email-masked]>; Martin Thomson <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: RE: Expectations for TLS session reuse

From: Eric Rescorla [mailto:[email-masked]]
Sent: Monday, December 12, 2016 2:24 PM
To: Mike Bishop <[email-masked]<mailto:[email-masked]>>
Cc: Lucas Pardue <[email-masked]<mailto:[email-masked]>>; Patrick McManus <[email-masked]<mailto:[email-masked]>>; Martin Thomson <[email-masked]<mailto:[email-masked]>>; HTTP Working Group <[email-masked]<mailto:[email-masked]>>
Subject: Re: Expectations for TLS session reuse

-Ekr

Regards
Lucas

http://www.bbc.co.uk

---------------------

---

From: Richard Bradbury <[email-masked]>
Date: Wed, 21 Dec 2016 12:50:49 +0000

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
> On Mon, Dec 12, 2016 at 9:53 AM, Mike Bishop wrote:
>
>     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
>     *To:* Patrick McManus; Martin Thomson
>     *Cc:* HTTP Working Group
>     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,
>
>     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.
>
>     > 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’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
>     *To:* Martin Thomson
>     *Cc:* Lucas Pardue ; HTTP Working Group
>     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:
>
>         On 9 December 2016 at 02:02, Lucas Pardue wrote:
>         >
>         > 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
>         > certificate with a subjectAlternateName that includes
>         example.net <http://example.net> and
>         > *.example.net <http://example.net>.
>         >
>         > the set of hosts, starting with example.net
>         <http://example.net> and then moving through the
>         > Our first test round used a client built on libcurl/7.29.0
>         and NSS/3.19.1. <http://3.19.1.>
>         > Out third test round used a recent version of Firefox. This
>         showed no
>         > session reuse.
>         >

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 21 Dec 2016 22:38:50 +0000

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

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

From: Lucas Pardue
To: Patrick McManus; Martin Thomson
Cc: HTTP Working Group

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.

--

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Dec 2016 09:52:33 +1100

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 <[email-masked]> 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.
>
>
>
> Cc: Eric Rescorla <[email-masked]>; Lucas Pardue <[email-masked]>;
> Patrick McManus <[email-masked]>; Martin Thomson
> <[email-masked]>; Mike Bishop <[email-masked]>
>
>
> 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/"."
>
> 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,
>
>
> 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
> 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,
>
>
>
> 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.
>
>
>
>> 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.
>
> 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.
>

---

From: Patrick McManus <[email-masked]>
Date: Wed, 21 Dec 2016 18:00:13 -0500

> because we each have different expectations.

I would also add that from an HTTPbis perspective, HTTP/1 transport
definitions are not likely to change. The vehicle for changing transport
features is in subsequent revisions of the protocol (which might or might
not imply QUIC) or perhaps extensions where possible.

We made a pretty clean break in H2 between transport and general HTTP
semantic things.. the latter typically have applicability across all
versions of HTTP, but transport changes are not as well suited to looking
backwards.

---

From: Richard Bradbury <[email-masked]>
Date: Thu, 22 Dec 2016 12:25:11 +0000

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:
>> From: Richard Bradbury
>> Cc: Eric Rescorla; Lucas Pardue; Patrick McManus; Martin Thomson; Mike Bishop

---

From: Patrick McManus <[email-masked]>
Date: Thu, 22 Dec 2016 10:39:02 -0500

On Thu, Dec 22, 2016 at 7:25 AM, Richard Bradbury <
[email-masked]> wrote:

> the position is the same for HTTP/1.1 as it is for HTTP/2

I don't think this is true. H1 is governed by 7230 section 9.. in practice
it is a connection per origin:

 The "https" scheme (Section 2.7.2
<https://tools.ietf.org/html/rfc7230#section-2.7.2>) is intended to
prevent (or at
   least reveal) many of these potential attacks on establishing
   authority, provided that the negotiated TLS connection is secured and
   the client properly verifies that the communicating server's identity
   matches the target URI's authority component (see [RFC2818
<https://tools.ietf.org/html/rfc2818>]).

whereas H2 loosens that a little bit for coalescing in 7540.

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 22 Dec 2016 17:43:44 +0200 (EET)

> If I attempt to do establish a TLS session on a new connection
> is that still called session resumption?

Session resumption have special meaning.

https://tools.ietf.org/html/rfc5246#section-7.4.1.2

|   The ClientHello message includes a variable-length session
|   identifier.  If not empty, the value identifies a session between the
|   same client and server whose security parameters the client wishes to
|   reuse.  The session identifier MAY be from an earlier connection,
|   this connection, or from another currently active connection.  The
|   second option is useful if the client only wishes to update the
|   random structures and derived values of a connection, and the third
|   option makes it possible to establish several independent secure
|   connections without repeating the full handshake protocol.  These
|   independent connections may occur sequentially or simultaneously; a
|   SessionID becomes valid when the handshake negotiating it completes
|   with the exchange of Finished messages and persists until it is
|   removed due to aging or because a fatal error was encountered on a
|   connection associated with the session.  The actual contents of the
|   SessionID are defined by the server.
|
|      opaque SessionID<0..32>;

|   session_id
|      The ID of a session the client wishes to use for this connection.
|      This field is empty if no session_id is available, or if the
|      client wishes to generate new security parameters.
|
|   cipher_suites
|      This is a list of the cryptographic options supported by the
|      client, with the client's first preference first.  If the
|      session_id field is not empty (implying a session resumption
|      request), this vector MUST include at least the cipher_suite from
|      that session.  Values are defined in Appendix A.5.

/ Kari Hurtta

---

From: Mike Bishop <[email-masked]>
Date: Thu, 22 Dec 2016 17:56:29 +0000

In theory, Richard is correct – “verif[y] that the communicating server’s identity matches the target URI’s authority component” could be considered satisfied if the cert were valid for the target name, even if it’s not the name the connection was originally opened to.

However, I don’t know of any HTTP/1.1 clients that actually implement it that way, and as I said before, I know of HTTP/1.1 servers that will refuse a request in that circumstance.  So as a practical matter, Patrick is correct too.

From: Patrick McManus [mailto:[email-masked]]
Sent: Thursday, December 22, 2016 7:39 AM
To: Richard Bradbury <[email-masked]>
Cc: Martin Thomson <[email-masked]>; Mike Bishop <[email-masked]>; [email-masked]; Eric Rescorla <[email-masked]>; Lucas Pardue <[email-masked]>; Patrick McManus <[email-masked]>
Subject: Re: Expectations for TLS session reuse

On Thu, Dec 22, 2016 at 7:25 AM, Richard Bradbury <[email-masked]<mailto:[email-masked]>> wrote:
the position is the same for HTTP/1.1 as it is for HTTP/2

I don't think this is true. H1 is governed by 7230 section 9.. in practice it is a connection per origin:

 The "https" scheme (Section 2.7.2<https://tools.ietf.org/html/rfc7230#section-2.7.2>) is intended to prevent (or at

   matches the target URI's authority component (see [RFC2818<https://tools.ietf.org/html/rfc2818>]).

---

From: Richard Bradbury <[email-masked]>
Date: Thu, 22 Dec 2016 18:04:31 +0000

On 22/12/2016 15:39, Patrick McManus wrote:
> On Thu, Dec 22, 2016 at 7:25 AM, Richard Bradbury wrote:
>
>   The "https" scheme (Section 2.7.2 <https://tools.ietf.org/html/rfc7230#section-2.7.2>) is intended to prevent (or at
>     matches the target URI's authority component (see [RFC2818 <https://tools.ietf.org/html/rfc2818>]).

Hmm... The statement in the above quotation seems inconclusive to me. 
Surely a client could verify the server's identity simply by checking 
that the target authority appears in the server's certificate (and that 
the certificate is valid too, of course...). Wouldn't that satisfy the 
security consideration on establishing authority described in section 9.1?

In search of something more explicit, I found this paragraph in section 
5.5 (Effective request URI):

    "Once the effective request URI has been constructed, an origin
    server needs to decide whether or not to provide service for that
    URI via the connection in which the request was received. For
    example, the request might have been misdirected, deliberately or
    accidentally, such that the information within a received
    request-target or Host header field differs from the host or port
    upon which the connection has been made. If the connection is from a
    trusted gateway, that inconsistency might be expected; otherwise, it
    might indicate an attempt to bypass security filters, trick the
    server into delivering non-public content, or poison a cache. See
    Section 9 <https://tools.ietf.org/html/rfc7230#section-9> for
    security considerations regarding message routing."

but that also doesn't seem very clear cut.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 23 Dec 2016 09:30:48 +1100

On 23 Dec 2016 5:04 AM, "Richard Bradbury" <[email-masked]>
wrote:

Hmm... The statement in the above quotation seems inconclusive to me.
Surely a client could verify the server's identity simply by checking that
the target authority appears in the server's certificate (and that the
certificate is valid too, of course...). Wouldn't that satisfy the security
consideration on establishing authority described in section 9.1?

Yes[1], if the cert is good and the name is right, that is enough.

Except... We still require that the IP address matches.  But only for
coalescing:

> 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.

It seems like the requirements for the initial connection are the only ones
that are ambiguous :)  ah the joys of dealing with specs.

Maybe I need to do a writeup. That isn't going to happen soon though. Keep
up the good work, and maybe you can write this up.

[1] The part that you might have been missing is how the valid certificate
is linked to a trust anchor.  That is where is gets much, much more
complicated.  (You might have meant to include that by saying  "valid", but
I wanted to be explicit.)