Re: [quicwg/base-drafts] Bound 0-to-1-RTT Transition (#2466)

Kazuho Oku <> Sat, 16 February 2019 00:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63DF913115E for <>; Fri, 15 Feb 2019 16:04:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ai4-2nhNPgId for <>; Fri, 15 Feb 2019 16:04:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B7B85131041 for <>; Fri, 15 Feb 2019 16:04:22 -0800 (PST)
Date: Fri, 15 Feb 2019 16:04:21 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1550275461; bh=546Q3fDej2oRJHp2BEeet5ZfTkrqWMRFaXbFZP1I9M8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=wSiK0ZtUS/mxPyMeyTA++9X/jAw6G8EfEsCtlJqvSt2j560DUQ2oZuqUk0XjDvH+b st6wsrwwUQJac4Lfao3gDE1ivHmvSgciaGGjOxxbfsjMS9QdfDk3T7Dsj6Yn4BR+zx 3FfXen0vYXFcb/+Smzs8fZbXvAcW8r1a5IwupQug=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2466/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Bound 0-to-1-RTT Transition (#2466)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c67538593ef5_34bd3fb4e72d45c025196"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 16 Feb 2019 00:04:25 -0000

@DavidSchinazi Spec-wise, my view is that we should recommend (or at least state that it's possible for) servers can enforce TP-values of previous TLS connection for 0-RTT packets, because not doing so means that the threat model of 0-RTT in QUIC will be different from that of TLS 1.3.

TLS 1.3 uses `max_early_data_size` field of NewSessionTicket message to cap the amount of application data the client is allowed to send in 0-RTT. And we have already built things around it. For example, [RFC 8470 section 3]( states, quote: _A server can limit the amount of early data with the "max_early_data_size" field of the "early_data" TLS extension.  This can be used to avoid committing an arbitrary amount of memory for requests that it might defer until the handshake completes._

Unless we provide a mechanism to replace the function that replaces `max_early_data_size` in QUIC, not only HTTP but every application protocol will be required to have different security considerations for using 0-RTT of TLS 1.3 and QUIC.

And implementation-wise, I think H2O/quicly might implement this due to the following reasons:
* H2O/quicly buffers requests that were deemed to early, instead of forwarding 425 to the client. Therefore we have memory pressure caused by 0-RTT stream data. That needs to be capped.
* It is after the HEADERS frame for the 0-RTT request is read out from the receive buffer that H2O receives a 425 from upstream. That means that we cannot rely on transport-level back pressure to avoid the peer sending additional data.

My understanding is that this type of implementation (i.e. buffering requests deemed to early, reading out HEADERS frame from receive buffer) is something we expect to see, and therefore it'd be unsurprising to see others also enforcing the limit.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: