Re: [quicwg/base-drafts] Describe interaction between QUIC and TLS regarding saved 0-RTT state (#2947)

Nick Harper <> Thu, 01 August 2019 22:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D0131201ED for <>; Thu, 1 Aug 2019 15:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 g2dRvPk5JrGV for <>; Thu, 1 Aug 2019 15:09:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F041112018C for <>; Thu, 1 Aug 2019 15:09:07 -0700 (PDT)
Date: Thu, 01 Aug 2019 15:09:06 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1564697346; bh=hMwDsgfULrpwKnAC8c4Y3h3/dVNeKrx31UN53yG3APs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=XNft3vNrrNYNiM6ClM9yPH5IOrzokpDa1XiZMqiG8ahUmC5bR4UVka4go2txY+mOr JT+6l5cxvkyNZIIiL/+7zxfGh/osILM7RV8Q6pUzXGUSa1BLImW15qzSIUptEoZjan IITlW0sYa46ragEsztTh07FtN044Md0GNCJuTbKE=
From: Nick Harper <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2947/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Describe interaction between QUIC and TLS regarding saved 0-RTT state (#2947)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d436302d25f9_308e3fcdfbacd95c140822"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nharper
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: Thu, 01 Aug 2019 22:09:09 -0000

nharper commented on this pull request.

> @@ -629,6 +632,24 @@ A client MAY attempt to send 0-RTT again if it receives a Retry or Version
 Negotiation packet.  These packets do not signify rejection of 0-RTT.
+## Validating saved 0-RTT state
+When a server receives a ClientHello with the "early_data" extension, it has to
+decide whether to accept or rejct early data from the client. Some of this
+decision is made by the TLS stack (e.g. checking that the cipher suite being
+resumed was included in the ClientHello, see Section 4.2.10 of {{!TLS13}}). QUIC
+saves additional transport and application state in a 0-RTT session ticket, and
+imposes additional restrictions on when a server may accept early data. The TLS
+stack needs to check with the QUIC stack whether this saved state is valid for
+accepting early data.
+One example of such state that the QUIC stack checks when deciding whether or
+not to accept early data is the transport parameters extension. When HTTP/3
+({{QUIC-HTTP}}) is used at the application layer, the SETTINGS frame from the

It's already an informative ref, defined at the beginning of the file.

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