RE: Expectations for TLS session reuse

Mike Bishop <Michael.Bishop@microsoft.com> Fri, 09 December 2016 18:12 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 0A59F1293F2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 9 Dec 2016 10:12:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.896
X-Spam-Level:
X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 QIPOkUE_pV4B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 9 Dec 2016 10:12:45 -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 30F99129410 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 9 Dec 2016 10:12:42 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cFPbz-0005K7-1C for ietf-http-wg-dist@listhub.w3.org; Fri, 09 Dec 2016 18:09:35 +0000
Resent-Date: Fri, 09 Dec 2016 18:09:35 +0000
Resent-Message-Id: <E1cFPbz-0005K7-1C@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 <Michael.Bishop@microsoft.com>) id 1cFPbf-0005I4-QY for ietf-http-wg@listhub.w3.org; Fri, 09 Dec 2016 18:09:15 +0000
Received: from mail-dm3nam03on0124.outbound.protection.outlook.com ([104.47.41.124] helo=NAM03-DM3-obe.outbound.protection.outlook.com) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from <Michael.Bishop@microsoft.com>) id 1cFPbW-00084D-Dz for ietf-http-wg@w3.org; Fri, 09 Dec 2016 18:09:10 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hZyUNMXOew+l7RVfKdjTWXhI870LtHF0qVJX3QqSwio=; b=Smhi44LaxlwgWJx79hSbavap0W1QmP2V7wHbwdLf9zaX1AWuV0i5qshhS73c02tCrHwkJmBSVKHLJFIkt4hlzXgB2fZagcajKIIHpzhydb4pAcMJ3oCkNimdmKX73qjurJoZANqvsZw+BDIRiVk6fiizl3F352UhmCtbWlDxATw=
Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Fri, 9 Dec 2016 18:08:38 +0000
Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0771.011; Fri, 9 Dec 2016 18:08:38 +0000
From: Mike Bishop <Michael.Bishop@microsoft.com>
To: Lucas Pardue <Lucas.Pardue@bbc.co.uk>, HTTP Working Group <ietf-http-wg@w3.org>
Thread-Topic: Expectations for TLS session reuse
Thread-Index: AdJSDroZqRm1YmE/R2CVfE2vNJEU+AAN/Hkg
Date: Fri, 09 Dec 2016 18:08:38 +0000
Message-ID: <BN6PR03MB270889564EF63A87400E693E87870@BN6PR03MB2708.namprd03.prod.outlook.com>
References: <7CF7F94CB496BF4FAB1676F375F9666A376AAB1E@bgb01xud1012>
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A376AAB1E@bgb01xud1012>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com;
x-originating-ip: [2601:600:8300:3b9a:c4bc:4eb6:5db4:9121]
x-ms-office365-filtering-correlation-id: 64915858-fc1c-4d0c-a88d-08d4205e668b
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2708;
x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:llLjrNtqW9OMvK3GObupS2gpKJzOcloXThLhfGpT8vcByNQynXYcodPVuWeaXRrh96KwsjrAFFU5LmbIQH3zAgj6gzfP01d3a0J9emL8qcdyGzcuPDTEmeej2YAJUHa4J4m7VqnsNBetnFHJ5jZOCUHDq9Kd4eQuBxRuIeT7gJgz/bbbbaYjcW7bBMh7GqbcJhwFe4yALShbpeHdhA/m7FvUrFMPz39FeO1SycRDu2UgFzrUBCfsLReiKp5GulnQDfa4Roebk4FYhpA+UdkpBS/jP8XnaQkS2yCIlO9NbJYYTAABSVBFtsLyEcm9nSO3mMptro8gx7MI+zsmVKk0YeExoLWQ14LbQ+orAZAjXJ3EgckafOmM+yzJl/lBMt2QpGD09Kh1LcdhFbHsKkEfwlhFb8PHuKRqdlln1keysJdtAOuesA72JNtsm72+YdmKOGOaHLhSytOy4MkMx0yUfxepgbURHATQFs/ENOItBmk=
x-microsoft-antispam-prvs: <BN6PR03MB2708D2A10F64561D416E4DCD87870@BN6PR03MB2708.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(150554046322364)(207263159765521)(127952516941037)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6042181)(6072148)(6047074); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708;
x-forefront-prvs: 015114592F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(53754006)(189002)(377454003)(81166006)(81156014)(9686002)(8936002)(33656002)(8676002)(10090500001)(105586002)(99286002)(106356001)(7736002)(54356999)(3280700002)(2906002)(50986999)(76176999)(101416001)(8990500004)(6116002)(790700001)(10290500002)(5005710100001)(102836003)(122556002)(107886002)(92566002)(189998001)(5660300001)(76576001)(2900100001)(3660700001)(5001770100001)(97736004)(229853002)(2950100002)(7906003)(68736007)(606005)(6506006)(77096006)(6436002)(7696004)(74316002)(86362001)(38730400001)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR03MB270889564EF63A87400E693E87870BN6PR03MB2708namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2016 18:08:38.4434 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708
Received-SPF: pass client-ip=104.47.41.124; envelope-from=Michael.Bishop@microsoft.com; helo=NAM03-DM3-obe.outbound.protection.outlook.com
X-W3C-Hub-Spam-Status: No, score=-4.3
X-W3C-Hub-Spam-Report: AWL=-2.739, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, W3C_NW=0.5
X-W3C-Scan-Sig: mimas.w3.org 1cFPbW-00084D-Dz 6ab63e15ad2cf95bcd5264f226465be1
X-Original-To: ietf-http-wg@w3.org
Subject: RE: Expectations for TLS session reuse
Archived-At: <http://www.w3.org/mid/BN6PR03MB270889564EF63A87400E693E87870@BN6PR03MB2708.namprd03.prod.outlook.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33145
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>

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:Lucas.Pardue@bbc.co.uk]
Sent: Friday, December 9, 2016 4:03 AM
To: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Expectations for TLS session reuse

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