Expectations for TLS session reuse

Lucas Pardue <Lucas.Pardue@bbc.co.uk> Fri, 09 December 2016 12:19 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 6669A129B80 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 9 Dec 2016 04:19:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.796
X-Spam-Status: No, score=-9.796 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=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Ovt_bhJoekUk for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 9 Dec 2016 04:19:11 -0800 (PST)
Received: from frink.w3.org (frink.w3.org []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29C7129BEF for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 9 Dec 2016 04:07:11 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cFJtx-00037F-VS for ietf-http-wg-dist@listhub.w3.org; Fri, 09 Dec 2016 12:03:46 +0000
Resent-Date: Fri, 09 Dec 2016 12:03:45 +0000
Resent-Message-Id: <E1cFJtx-00037F-VS@frink.w3.org>
Received: from mimas.w3.org ([]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <Lucas.Pardue@bbc.co.uk>) id 1cFJtg-00035O-CO for ietf-http-wg@listhub.w3.org; Fri, 09 Dec 2016 12:03:28 +0000
Received: from mailout1.telhc.bbc.co.uk ([]) by mimas.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from <Lucas.Pardue@bbc.co.uk>) id 1cFJtU-0003X5-Co for ietf-http-wg@w3.org; Fri, 09 Dec 2016 12:03:23 +0000
Received: from BGB01XI1012.national.core.bbc.co.uk (bgb01xi1012.national.core.bbc.co.uk []) by mailout1.telhc.bbc.co.uk (8.15.2/8.14.3) with ESMTP id uB9C2qnQ003721 for <ietf-http-wg@w3.org>; Fri, 9 Dec 2016 12:02:52 GMT
Received: from BGB01XUD1012.national.core.bbc.co.uk ([]) by BGB01XI1012.national.core.bbc.co.uk ([]) with mapi id 14.03.0319.002; Fri, 9 Dec 2016 12:02:52 +0000
From: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
To: HTTP Working Group <ietf-http-wg@w3.org>
Thread-Topic: Expectations for TLS session reuse
Thread-Index: AdJSDroZqRm1YmE/R2CVfE2vNJEU+A==
Date: Fri, 09 Dec 2016 12:02:51 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A376AAB1E@bgb01xud1012>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--28.286200-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A376AAB1Ebgb01xud1012_"
MIME-Version: 1.0
Received-SPF: pass client-ip=; envelope-from=Lucas.Pardue@bbc.co.uk; helo=mailout1.telhc.bbc.co.uk
X-W3C-Hub-Spam-Status: No, score=-6.4
X-W3C-Hub-Spam-Report: AWL=0.289, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.999, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, W3C_NW=0.5
X-W3C-Scan-Sig: mimas.w3.org 1cFJtU-0003X5-Co 24e55b2b8661758b07e8c2cbf18b5318
X-Original-To: ietf-http-wg@w3.org
Subject: Expectations for TLS session reuse
Archived-At: <http://www.w3.org/mid/7CF7F94CB496BF4FAB1676F375F9666A376AAB1E@bgb01xud1012>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33144
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>

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?