Re: Expectations for TLS session reuse

Richard Bradbury <richard.bradbury@rd.bbc.co.uk> Thu, 22 December 2016 18:07 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 C3C6B12978B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 22 Dec 2016 10:07:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10
X-Spam-Level:
X-Spam-Status: No, score=-10 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=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 lWkY9XAwVCUq for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 22 Dec 2016 10:07:13 -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 63CA9129781 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 22 Dec 2016 10:07:13 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cK7ju-0008KC-Rn for ietf-http-wg-dist@listhub.w3.org; Thu, 22 Dec 2016 18:05:14 +0000
Resent-Date: Thu, 22 Dec 2016 18:05:14 +0000
Resent-Message-Id: <E1cK7ju-0008KC-Rn@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 <richard.bradbury@rd.bbc.co.uk>) id 1cK7jl-0008J0-Pd for ietf-http-wg@listhub.w3.org; Thu, 22 Dec 2016 18:05:05 +0000
Received: from gateh.kw.bbc.co.uk ([132.185.132.17]) by mimas.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from <richard.bradbury@rd.bbc.co.uk>) id 1cK7jk-00048o-IR for ietf-http-wg@w3.org; Thu, 22 Dec 2016 18:05:05 +0000
Received: from mailhub0.rd.bbc.co.uk ([172.29.120.128]) by gateh.kw.bbc.co.uk (8.14.5+Sun/8.13.6) with ESMTP id uBMI4Van001812; Thu, 22 Dec 2016 18:04:32 GMT
Received: from rd000299.rd.bbc.co.uk ([172.29.136.177]:58418) by mailhub0.rd.bbc.co.uk with esmtp (Exim 4.84_2) (envelope-from <richard.bradbury@rd.bbc.co.uk>) id 1cK7jD-0005I5-NY; Thu, 22 Dec 2016 18:04:31 +0000
To: Patrick McManus <mcmanus@ducksong.com>
References: <7CF7F94CB496BF4FAB1676F375F9666A376AAB1E@bgb01xud1012> <CABkgnnWOrphhWpjuhRC5apydWb2t=qWvMSb1D9uo8Eb_4JHzqQ@mail.gmail.com> <CAOdDvNo2OgdkuDCjeVZBRnB+JPg0eFtPcm_UXQPhrEuiaGKGaw@mail.gmail.com> <7CF7F94CB496BF4FAB1676F375F9666A376B04C7@bgb01xud1012> <BN6PR03MB2708F28F1828C5278E71938087980@BN6PR03MB2708.namprd03.prod.outlook.com> <CABcZeBMssBzM67iLGtKQgS0KgSj6q9tZX7hG0GNfSK=VvatuWw@mail.gmail.com> <BN6PR03MB270885404C2F1E029F54AABE879B0@BN6PR03MB2708.namprd03.prod.outlook.com> <97158afb-d80a-443c-b59a-209ffe3d34d9@rd.bbc.co.uk> <BN6PR03MB2708A286DF303E6524EF9F4D87930@BN6PR03MB2708.namprd03.prod.outlook.com> <CABkgnnXAaX4+6CbWQGFm_0bk82WZNq9d=UBmaq22u2q7yP+pUQ@mail.gmail.com> <e508d3c7-c81d-91d8-7b6d-3e2b74d15bd9@rd.bbc.co.uk> <CAOdDvNqPDssNmSscgk3chbPg+Uw53_nqFrv+OzhTHWA=hTvwLg@mail.gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Mike Bishop <Michael.Bishop@microsoft.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Eric Rescorla <ekr@rtfm.com>, Lucas Pardue <Lucas.Pardue@bbc.co.uk>
From: Richard Bradbury <richard.bradbury@rd.bbc.co.uk>
Message-ID: <4acbd46a-ebec-2727-96d3-b668a947856c@rd.bbc.co.uk>
Date: Thu, 22 Dec 2016 18:04:31 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <CAOdDvNqPDssNmSscgk3chbPg+Uw53_nqFrv+OzhTHWA=hTvwLg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------3505098E6388E7FC89D30F0B"
Received-SPF: none client-ip=132.185.132.17; envelope-from=richard.bradbury@rd.bbc.co.uk; helo=gateh.kw.bbc.co.uk
X-W3C-Hub-Spam-Status: No, score=-7.0
X-W3C-Hub-Spam-Report: AWL=0.037, BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.1, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1cK7jk-00048o-IR 4cb9979fa4e81be13b2b5093300616c5
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Expectations for TLS session reuse
Archived-At: <http://www.w3.org/mid/4acbd46a-ebec-2727-96d3-b668a947856c@rd.bbc.co.uk>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33224
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>

On 22/12/2016 15:39, Patrick McManus wrote:
> On Thu, Dec 22, 2016 at 7:25 AM, Richard Bradbury wrote:
>
>     the position is the same for HTTP/1.1 as it is for HTTP/2
>
>
> I don't think this is true. H1 is governed by 7230 section 9.. in 
> practice it is a connection per origin:
>   The "https" scheme (Section 2.7.2 <https://tools.ietf.org/html/rfc7230#section-2.7.2>) is intended to prevent (or at
>     least reveal) many of these potential attacks on establishing
>     authority, provided that the negotiated TLS connection is secured and
>     the client properly verifies that the communicating server's identity
>     matches the target URI's authority component (see [RFC2818 <https://tools.ietf.org/html/rfc2818>]).
> whereas H2 loosens that a little bit for coalescing in 7540.

Hmm... The statement in the above quotation seems inconclusive to me. 
Surely a client could verify the server's identity simply by checking 
that the target authority appears in the server's certificate (and that 
the certificate is valid too, of course...). Wouldn't that satisfy the 
security consideration on establishing authority described in section 9.1?

In search of something more explicit, I found this paragraph in section 
5.5 (Effective request URI):

    "Once the effective request URI has been constructed, an origin
    server needs to decide whether or not to provide service for that
    URI via the connection in which the request was received. For
    example, the request might have been misdirected, deliberately or
    accidentally, such that the information within a received
    request-target or Host header field differs from the host or port
    upon which the connection has been made. If the connection is from a
    trusted gateway, that inconsistency might be expected; otherwise, it
    might indicate an attempt to bypass security filters, trick the
    server into delivering non-public content, or poison a cache. See
    Section 9 <https://tools.ietf.org/html/rfc7230#section-9> for
    security considerations regarding message routing."

but that also doesn't seem very clear cut.

-- 
Richard Bradbury | Lead Research Engineer
BBC Research & Development
Centre House, 56 Wood Lane, London  W12 7SB.
T: 0303 040 9672  F: 020 8811 8815