Re: [quicwg/base-drafts] 0-RTT can't use transport parameters or 1-RTT frames (#2461)

MikkelFJ <> Wed, 13 February 2019 15:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EBC4212DDA3 for <>; Wed, 13 Feb 2019 07:38:29 -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_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 UpAj8HQ2jFkq for <>; Wed, 13 Feb 2019 07:38:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 20771126C7E for <>; Wed, 13 Feb 2019 07:38:28 -0800 (PST)
Date: Wed, 13 Feb 2019 07:38:27 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1550072307; bh=uLqyfLRTRqzTA/2lOqPioaF+85nJgw0hAMVFbL7ue28=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=akKZVFcS+PJaRRKcu0qPei+nm06TM1ZEOciDyVpwcpsJueFIug0UFwZW3G6/P/Cd3 aknqIHltyJPEbzJQjSbhGfoLSPzw4XVjV0ydxGRR0RBAgv0obXN9U/xf+sXkE4uQPB 5OgR1bJpYS8WY+s+YHpLElH+YboInoscbswdGR2A=
From: MikkelFJ <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2461/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] 0-RTT can't use transport parameters or 1-RTT frames (#2461)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c6439f31bd52_742a3fc193ad45b4630e6"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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: Wed, 13 Feb 2019 15:38:30 -0000

mikkelfj commented on this pull request.

 A client SHOULD instead generate a fresh cryptographic handshake message and
 start packet numbers from 0.  This ensures that new 0-RTT packets will not use
 the same keys, avoiding any risk of key and nonce reuse; this also prevents
 0-RTT packets from previous handshake attempts from being accepted as part of
 the connection.
+A client MUST NOT send 0-RTT packets once it starts processing 1-RTT packets
+from the server.  This means that 0-RTT packets can't contain any response to
+frames from 1-RTT packets.  For instance, a client cannot send an ACK frame in a
+0-RTT packet, because that can only acknowledge a 1-RTT packet.  An
+acknowledgment for a 1-RTT packet MUST be carried in a 1-RTT packet.

A server MAY close a connection with the error PROTOCOL_VIOLATION if it is able to observe that a client sends 0-RTT packets based on any information received in 1-RTT packets, such as using increased flow control credits or stream identifiers.

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