Re: Expectations for TLS session reuse

Eric Rescorla <ekr@rtfm.com> Mon, 12 December 2016 22:35 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 74039129DBC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 12 Dec 2016 14:35:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.796
X-Spam-Level:
X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 UXcU36jY-5bL for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 12 Dec 2016 14:35:50 -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 F0C1D129DC0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 12 Dec 2016 14:28:17 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cGZ2C-0004tX-NR for ietf-http-wg-dist@listhub.w3.org; Mon, 12 Dec 2016 22:25:24 +0000
Resent-Date: Mon, 12 Dec 2016 22:25:24 +0000
Resent-Message-Id: <E1cGZ2C-0004tX-NR@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 <ekr@rtfm.com>) id 1cGZ1n-0003DW-Ft for ietf-http-wg@listhub.w3.org; Mon, 12 Dec 2016 22:24:59 +0000
Received: from mail-yb0-f173.google.com ([209.85.213.173]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <ekr@rtfm.com>) id 1cGZ1f-0001qB-Uu for ietf-http-wg@w3.org; Mon, 12 Dec 2016 22:24:54 +0000
Received: by mail-yb0-f173.google.com with SMTP id v132so6628275yba.0 for <ietf-http-wg@w3.org>; Mon, 12 Dec 2016 14:24:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CmuRC2mqD6AbjcE5Zr3iGGt4Gqt05Nf/mw1AsbAV2ic=; b=Q0L5fUzeYjofmXzT5QUutu24Ks+4VE9GirmakXNxRiYGlBjsElU5bhWoXpCwn7eIjT RKjxUGqemvjViyqkAl5CCrKWEF8+YngVbFoM3l3wnYNoa3pexIkAzxVCwwNZX+VppurO Ofp2eFEW8HH1darjVcE4Mf5SguglhF6ySgc5792np2CasgC3WSzwXzZUwsu9oGb8lj4b tBS46C/Tl2MISN3DYfuCATaOYW39IwWFRrw+6hbOUSjABLmM7RmOf6Eioqiw4Jq952Rd 7226maEUue0QNz9XJsuK+5r7seXtkrl9oM7UyqIrcz256/Jg3XqV8YX8QGtiEb2emDn0 bA1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CmuRC2mqD6AbjcE5Zr3iGGt4Gqt05Nf/mw1AsbAV2ic=; b=gEtymq4ZLc3ZHhuhC7GNh0QTkJOWDytlVVWxgagCxrijzAAgK1IBYbce83OoqbHwYb gNYs2wLUcpM8Dgnf0rQ0WhVvrvRye/po0mN7n6IkRPUNbuWQ4ynd7ZR6NFm/L5M+ybIu NS8lgbcEnMG+xVPygMy8/cUwqbDXTLqss4U5WUEx2p0OD1V7Ugk+0i0kAY4P/4N+x1m5 J5zWFOe80JjHKGAD5euuArGTPialYDpKP1JOW6Muo5+cscZbocCgkUBYUIcNqvC85h+y dIjVGAVRBwTe2+fS2eZXbiJ0lZD6b6UeWmrpGndiXA+GwlP8bgHVlEv7VkBWFYPiriF2 SkGw==
X-Gm-Message-State: AKaTC01LM3L70L+BiJwvSIwn8Y+vVV18bLi/tlCrMzm2C4ALY68C9qZ6yc98Txk0iFUtAE6cNaiPadmD2qMXpw==
X-Received: by 10.37.205.196 with SMTP id d187mr49849497ybf.161.1481581465170; Mon, 12 Dec 2016 14:24:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.164.210 with HTTP; Mon, 12 Dec 2016 14:23:44 -0800 (PST)
In-Reply-To: <BN6PR03MB2708F28F1828C5278E71938087980@BN6PR03MB2708.namprd03.prod.outlook.com>
References: <7CF7F94CB496BF4FAB1676F375F9666A376AAB1E@bgb01xud1012> <CABkgnnWOrphhWpjuhRC5apydWb2t=qWvMSb1D9uo8Eb_4JHzqQ@mail.gmail.com> <CAOdDvNo2OgdkuDCjeVZBRnB+JPg0eFtPcm_UXQPhrEuiaGKGaw@mail.gmail.com> <7CF7F94CB496BF4FAB1676F375F9666A376B04C7@bgb01xud1012> <BN6PR03MB2708F28F1828C5278E71938087980@BN6PR03MB2708.namprd03.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 12 Dec 2016 14:23:44 -0800
Message-ID: <CABcZeBMssBzM67iLGtKQgS0KgSj6q9tZX7hG0GNfSK=VvatuWw@mail.gmail.com>
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Lucas Pardue <Lucas.Pardue@bbc.co.uk>, Patrick McManus <mcmanus@ducksong.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=94eb2c189a2ef02c8e05437d900e
Received-SPF: none client-ip=209.85.213.173; envelope-from=ekr@rtfm.com; helo=mail-yb0-f173.google.com
X-W3C-Hub-Spam-Status: No, score=-6.3
X-W3C-Hub-Spam-Report: AWL=-0.371, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1cGZ1f-0001qB-Uu fcf5d3a2eb50f0c261e5f450a5ddee69
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Expectations for TLS session reuse
Archived-At: <http://www.w3.org/mid/CABcZeBMssBzM67iLGtKQgS0KgSj6q9tZX7hG0GNfSK=VvatuWw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33155
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>

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 <Michael.Bishop@microsoft.com>
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 [mailto:Lucas.Pardue@bbc.co.uk]
> *Sent:* Monday, December 12, 2016 9:21 AM
> *To:* Patrick McManus <mcmanus@ducksong.com>om>; Martin Thomson <
> martin.thomson@gmail.com>
> *Cc:* HTTP Working Group <ietf-http-wg@w3.org>
> *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?
>
>
>
> Regards
>
> Lucas
>
>
>
>
>
> *From:* Patrick McManus [mailto:mcmanus@ducksong.com
> <mcmanus@ducksong.com>]
> *Sent:* 09 December 2016 22:58
> *To:* Martin Thomson <martin.thomson@gmail.com>
> *Cc:* Lucas Pardue <Lucas.Pardue@bbc.co.uk>uk>; HTTP Working Group <
> ietf-http-wg@w3.org>
> *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.
>
> -Patrick
>
>
>
>
>
> On Fri, Dec 9, 2016 at 9:19 AM, Martin Thomson <martin.thomson@gmail.com>
> 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 <Lucas.Pardue@bbc.co.uk> 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.
> >
> >
> >
> > 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
> >
> >
>
>
>
>
>
> ----------------------------
>
> 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.
>
> ---------------------
>