Re: Expectations for TLS session reuse

Richard Bradbury <richard.bradbury@rd.bbc.co.uk> Wed, 21 December 2016 12:55 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D5F128B44 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 21 Dec 2016 04:55:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10
X-Spam-Level:
X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVlT_vdk73D7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 21 Dec 2016 04:55:06 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A895E1295C3 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 21 Dec 2016 04:55:06 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cJgN3-00026S-8R for ietf-http-wg-dist@listhub.w3.org; Wed, 21 Dec 2016 12:51:49 +0000
Resent-Date: Wed, 21 Dec 2016 12:51:49 +0000
Resent-Message-Id: <E1cJgN3-00026S-8R@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <richard.bradbury@rd.bbc.co.uk>) id 1cJgMj-00024X-FZ for ietf-http-wg@listhub.w3.org; Wed, 21 Dec 2016 12:51:29 +0000
Received: from gateh.kw.bbc.co.uk ([132.185.132.17]) by titan.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from <richard.bradbury@rd.bbc.co.uk>) id 1cJgMb-0005sY-Vm for ietf-http-wg@w3.org; Wed, 21 Dec 2016 12:51:24 +0000
Received: from mailhub0.rd.bbc.co.uk ([172.29.120.128]) by gateh.kw.bbc.co.uk (8.14.5+Sun/8.13.6) with ESMTP id uBLCon4j001329; Wed, 21 Dec 2016 12:50:49 GMT
Received: from rd000299.rd.bbc.co.uk ([172.29.136.177]:55107) by mailhub0.rd.bbc.co.uk with esmtp (Exim 4.84_2) (envelope-from <richard.bradbury@rd.bbc.co.uk>) id 1cJgM5-0008U4-E5; Wed, 21 Dec 2016 12:50:49 +0000
To: ietf-http-wg@w3.org
References: <7CF7F94CB496BF4FAB1676F375F9666A376AAB1E@bgb01xud1012> <CABkgnnWOrphhWpjuhRC5apydWb2t=qWvMSb1D9uo8Eb_4JHzqQ@mail.gmail.com> <CAOdDvNo2OgdkuDCjeVZBRnB+JPg0eFtPcm_UXQPhrEuiaGKGaw@mail.gmail.com> <7CF7F94CB496BF4FAB1676F375F9666A376B04C7@bgb01xud1012> <BN6PR03MB2708F28F1828C5278E71938087980@BN6PR03MB2708.namprd03.prod.outlook.com> <CABcZeBMssBzM67iLGtKQgS0KgSj6q9tZX7hG0GNfSK=VvatuWw@mail.gmail.com> <BN6PR03MB270885404C2F1E029F54AABE879B0@BN6PR03MB2708.namprd03.prod.outlook.com>
From: Richard Bradbury <richard.bradbury@rd.bbc.co.uk>
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>
Date: Wed, 21 Dec 2016 12:50:49 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <BN6PR03MB270885404C2F1E029F54AABE879B0@BN6PR03MB2708.namprd03.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------AC0FED0A0EAE83E08AC35208"
Received-SPF: none client-ip=132.185.132.17; envelope-from=richard.bradbury@rd.bbc.co.uk; helo=gateh.kw.bbc.co.uk
X-W3C-Hub-Spam-Status: No, score=-6.9
X-W3C-Hub-Spam-Report: AWL=0.049, BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.1, URIBL_BLOCKED=0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1cJgMb-0005sY-Vm 075c9dc6c86b6527cdaf5fff95562d40
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Expectations for TLS session reuse
Archived-At: <http://www.w3.org/mid/97158afb-d80a-443c-b59a-209ffe3d34d9@rd.bbc.co.uk>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33210
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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