Re: 0-RTT Design for HTTP/2
Willy Tarreau <w@1wt.eu> Sat, 19 December 2020 17:21 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 6DE4F3A0D7E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 19 Dec 2020 09:21:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.648
X-Spam-Level:
X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 a4_AZgxfk7zZ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 19 Dec 2020 09:21:54 -0800 (PST)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D51A3A0D7C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 19 Dec 2020 09:21:54 -0800 (PST)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1kqfsd-0002mZ-3R for ietf-http-wg-dist@listhub.w3.org; Sat, 19 Dec 2020 17:18:56 +0000
Resent-Date: Sat, 19 Dec 2020 17:18:55 +0000
Resent-Message-Id: <E1kqfsd-0002mZ-3R@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <w@1wt.eu>) id 1kqfsb-0002lj-FD for ietf-http-wg@listhub.w3.org; Sat, 19 Dec 2020 17:18:53 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by mimas.w3.org with esmtp (Exim 4.92) (envelope-from <w@1wt.eu>) id 1kqfsZ-0006vo-AV for ietf-http-wg@w3.org; Sat, 19 Dec 2020 17:18:53 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 0BJHIZ8E018953; Sat, 19 Dec 2020 18:18:35 +0100
Date: Sat, 19 Dec 2020 18:18:35 +0100
From: Willy Tarreau <w@1wt.eu>
To: Martin Thomson <mt@lowentropy.net>
Cc: ietf-http-wg@w3.org
Message-ID: <20201219171835.GB18787@1wt.eu>
References: <126ee381-7828-451f-865a-db6357928243@www.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <126ee381-7828-451f-865a-db6357928243@www.fastmail.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-7.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1kqfsZ-0006vo-AV b39b57f7cbe3713d84f6d2440487d277
X-Original-To: ietf-http-wg@w3.org
Subject: Re: 0-RTT Design for HTTP/2
Archived-At: <https://www.w3.org/mid/20201219171835.GB18787@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38328
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: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Hi Martin, On Wed, Dec 16, 2020 at 06:11:58PM +1100, Martin Thomson wrote: > As part of our adoption call for HTTP/2 (reprise), I opened https://github.com/httpwg/http2-spec/issues/781 regarding the use of TLS early data. > > I thought that it might be worth the time to go through the exercise of defining an extension to h2 that enabled saving of settings across connections. Here it is: > > https://martinthomson.github.io/h2-0rtt/draft-thomson-httpbis-h2-0rtt.html I'm confused, maybe due to some of my limitations regarding the language, but I'm really confused by the fact that TLS is mixed in, and my knowledge of TLS is rather limited and seeing some parts speaking about TLS tickets totally lost me. My understanding was that if the server advertises EARLY_DATA_SETTINGS=1, then the client would assume the server kept the same settings. In my opinion this should be sufficient to let the client safely reuse these values for next connections. And BTW, this shouldn't prevent the server from emitting its settings frame anyway so that the client can check if anything changed. I see that Cory mentioned the fact that most implementations do not see the TLS layer, I can confirm this. For example in haproxy, h2 works on top of a streaming transport protocol. It can be plain or TLS on top of TCP, UNIX or socketpairs, we don't care. Early data, if any, are retrieved by the TLS layer and are prepended in front of the other data (more or less some details I don't remember regarding the necessary controls to figure whether or not some early data were involved for the request). Anything more complicated will likely become a showstopper I'm afraid. Maybe I misundersood something in the proposal, though. Cheers, Willy
- 0-RTT Design for HTTP/2 Martin Thomson
- Re: 0-RTT Design for HTTP/2 Cory Benfield
- Re: 0-RTT Design for HTTP/2 Ian Swett
- Re: 0-RTT Design for HTTP/2 David Schinazi
- Re: 0-RTT Design for HTTP/2 Martin Thomson
- Re: 0-RTT Design for HTTP/2 David Schinazi
- RE: 0-RTT Design for HTTP/2 Mike Bishop
- Re: 0-RTT Design for HTTP/2 Martin Thomson
- Re: 0-RTT Design for HTTP/2 Ian Swett
- Re: 0-RTT Design for HTTP/2 Willy Tarreau
- Re: 0-RTT Design for HTTP/2 Martin Thomson
- Re: 0-RTT Design for HTTP/2 Martin Thomson
- Re: 0-RTT Design for HTTP/2 Willy Tarreau
- Re: 0-RTT Design for HTTP/2 Martin Thomson
- Re: 0-RTT Design for HTTP/2 Ian Swett
- Re: 0-RTT Design for HTTP/2 Cory Benfield