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

Nick Harper <> Fri, 11 October 2019 20:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FE731200A3 for <>; Fri, 11 Oct 2019 13:22:40 -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 DdKOr3oKTafo for <>; Fri, 11 Oct 2019 13:22:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E711120096 for <>; Fri, 11 Oct 2019 13:22:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6963A6E09FE for <>; Fri, 11 Oct 2019 13:22:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1570825357; bh=dwHa2ycIbwbi21pmTlxrnQMaIqNFgkv47nP1co6U6d8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ZWIgGCsUtMAWbI8/eE3PaQLarzKXloxJ3e7AVWVHNiFQecJ8QuC9S52WFUWlg4zqt R+ff7BeCYbs++Ehjeyk+oRSxkrOZid/e2ODlojdXXUe9USbX0Tw2ydygi0Ko8/oMdJ 32bR607oXxbC0L+6uMPB8iD9Jkx3lVJiyr/3eL6Q=
Date: Fri, 11 Oct 2019 13:22:37 -0700
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_5da0e48d5a403_14c93f8b802cd96827437e"; 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: Fri, 11 Oct 2019 20:22:40 -0000

nharper commented on this pull request.

> @@ -644,6 +647,27 @@ 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 0-RTT Configuration
+When a server receives a ClientHello with the "early_data" extension, it has to
+decide whether to accept or reject 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}}). Even
+when the TLS stack has no reason to reject early data, the QUIC stack or the
+application protocol using QUIC might reject early data because the
+configuration of the transport or application associated with the resumed
+session is not compatible with the server's current configuration.
+QUIC requires additional transport state to be associated with a 0-RTT session
+ticket. If stateless session tickets are used, this information must be stored
+in the session ticket. Application protocols that use QUIC might have similar

The intention of that sentence was to say that most likely you're using stateless tickets and storing this additional state in the ticket, so I reworded it to say that.

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