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>; 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>; 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. > > --------------------- >
- Expectations for TLS session reuse Lucas Pardue
- RE: Expectations for TLS session reuse Mike Bishop
- Re: Expectations for TLS session reuse Martin Thomson
- Re: Expectations for TLS session reuse Patrick McManus
- RE: Expectations for TLS session reuse Lucas Pardue
- RE: Expectations for TLS session reuse Mike Bishop
- Re: Expectations for TLS session reuse Eric Rescorla
- RE: Expectations for TLS session reuse Mike Bishop
- RE: Expectations for TLS session reuse Lucas Pardue
- Re: Expectations for TLS session reuse Richard Bradbury
- RE: Expectations for TLS session reuse Mike Bishop
- Re: Expectations for TLS session reuse Martin Thomson
- Re: Expectations for TLS session reuse Patrick McManus
- Re: Expectations for TLS session reuse Richard Bradbury
- Re: Expectations for TLS session reuse Patrick McManus
- Re: Expectations for TLS session reuse Kari Hurtta
- RE: Expectations for TLS session reuse Mike Bishop
- Re: Expectations for TLS session reuse Richard Bradbury
- Re: Expectations for TLS session reuse Martin Thomson