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

Nick Harper <> Tue, 08 October 2019 23:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1481E1200B6 for <>; Tue, 8 Oct 2019 16:22:20 -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 sE5RlPh5xCx5 for <>; Tue, 8 Oct 2019 16:22:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 98618120046 for <>; Tue, 8 Oct 2019 16:22:18 -0700 (PDT)
Date: Tue, 08 Oct 2019 16:22:17 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1570576937; bh=vGlqteV0gI1STa7oo2GqvlSIQHnISoy3GmExvDPm01g=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=0vw4QBbGYNcxDDyWgvaFKlJUL030QwitVCMLRRSWZY/9SJC91u+w9uZlV/KtVkdhq 954mqHqHG3CVSye22f9X1ZGQZoq7KbSBPKt+V5+JtzGaDTiyLoni7Yq0KC53O+Hrog zKvZKUmBCHNFDjgypufc09hjzTJFZyCtZVOpImtQ=
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_5d9d1a298fa65_41d13f8a6e6cd9681193c3"; 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: Tue, 08 Oct 2019 23:22:20 -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

Would it work to change "If stateless session tickets are used, this information must be stored in the session ticket." to "If stateless session tickets are used, this information may be stored in the session ticket."?

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