Re: Expectations for TLS session reuse

Patrick McManus <mcmanus@ducksong.com> Fri, 09 December 2016 23:01 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 04C0012958D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 9 Dec 2016 15:01:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.449
X-Spam-Level:
X-Spam-Status: No, score=-8.449 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_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sendgrid.me
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 0ecQLW2rO0yX for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 9 Dec 2016 15:01:52 -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 73757128E19 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 9 Dec 2016 15:01:52 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cFU7g-0002MA-HX for ietf-http-wg-dist@listhub.w3.org; Fri, 09 Dec 2016 22:58:36 +0000
Resent-Date: Fri, 09 Dec 2016 22:58:36 +0000
Resent-Message-Id: <E1cFU7g-0002MA-HX@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <bounces+1568871-208f-ietf-http-wg=w3.org@sendgrid.net>) id 1cFU7X-0002LH-U4 for ietf-http-wg@listhub.w3.org; Fri, 09 Dec 2016 22:58:27 +0000
Received: from o1.7nn.fshared.sendgrid.net ([167.89.55.65]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <bounces+1568871-208f-ietf-http-wg=w3.org@sendgrid.net>) id 1cFU7P-0006az-7A for ietf-http-wg@w3.org; Fri, 09 Dec 2016 22:58:22 +0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.me; h=mime-version:in-reply-to:references:from:subject:to:cc:content-type; s=smtpapi; bh=ipC1pXwzBhfA/mxRfsb1fnEVw+g=; b=rv2NipDwzqYq9YGQEB pbV1rlBk8sYerE8ZHF7H19aNE1gy9M9pnD+uj0Gnpmnasu9XmIkMT5rKair17Zhj HpXpwcWZiZRwptBosXvWOFOxY42gd5UhtVXvzTmZE2sI6p4oUD+dtAR39RQ6BGty eCLoDg0+IJliynz76Eeju9vng=
Received: by filter0937p1mdw1.sendgrid.net with SMTP id filter0937p1mdw1-27411-584B36EF-28 2016-12-09 22:57:51.619380607 +0000 UTC
Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) by ismtpd0003p1iad1.sendgrid.net (SG) with ESMTP id 68KUZ-idRTmQ1N9fnfP4TQ for <ietf-http-wg@w3.org>; Fri, 09 Dec 2016 22:57:51.507 +0000 (UTC)
Received: by mail-io0-f170.google.com with SMTP id p42so86917117ioo.1 for <ietf-http-wg@w3.org>; Fri, 09 Dec 2016 14:57:51 -0800 (PST)
X-Gm-Message-State: AKaTC03QMsKCotkQLoPPbeDgLtYSQe4QWp5nJloH0J/EMylttAP266fFzaaTJvQgHPO8K7963u1TKX1Ir4FrCQ==
X-Received: by 10.107.57.135 with SMTP id g129mr65788318ioa.178.1481324271071; Fri, 09 Dec 2016 14:57:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.19.16 with HTTP; Fri, 9 Dec 2016 14:57:50 -0800 (PST)
In-Reply-To: <CABkgnnWOrphhWpjuhRC5apydWb2t=qWvMSb1D9uo8Eb_4JHzqQ@mail.gmail.com>
References: <7CF7F94CB496BF4FAB1676F375F9666A376AAB1E@bgb01xud1012> <CABkgnnWOrphhWpjuhRC5apydWb2t=qWvMSb1D9uo8Eb_4JHzqQ@mail.gmail.com>
From: Patrick McManus <mcmanus@ducksong.com>
Date: Fri, 9 Dec 2016 12:57:50 -1000
X-Gmail-Original-Message-ID: <CAOdDvNo2OgdkuDCjeVZBRnB+JPg0eFtPcm_UXQPhrEuiaGKGaw@mail.gmail.com>
Message-ID: <CAOdDvNo2OgdkuDCjeVZBRnB+JPg0eFtPcm_UXQPhrEuiaGKGaw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Lucas Pardue <Lucas.Pardue@bbc.co.uk>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=001a114ac3e2f979c0054341aedb
X-SG-EID: YLWet4rakcOTMHWvPPwWbcsiUJbN1FCn0PHYd/Uujh6yjhpXJLM3MGtBNbuxYQxfoCoaXyq2jYJko5 8EKxpd2/gHeEDqcadCOLPWP+cVeMgwpH+W7IJAtjB47a6PMriqHhbpvLFt4hjQnZeD5EyHHilbGmoC SOyPVU709vuN2bbSGuxi7VDZxeyTc0hXL2jTjb1yBUaghDZMykLhwA7hqyljCqI588Ek9ZoI3AJj8D I=
Received-SPF: pass client-ip=167.89.55.65; envelope-from=bounces+1568871-208f-ietf-http-wg=w3.org@sendgrid.net; helo=o1.7nn.fshared.sendgrid.net
X-W3C-Hub-Spam-Status: No, score=-6.4
X-W3C-Hub-Spam-Report: AWL=0.172, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.999, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1cFU7P-0006az-7A 5e8665d22de9e0ea604038a22b431eaa
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Expectations for TLS session reuse
Archived-At: <http://www.w3.org/mid/CAOdDvNo2OgdkuDCjeVZBRnB+JPg0eFtPcm_UXQPhrEuiaGKGaw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33149
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>

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