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