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

Mike Bishop <> Thu, 18 April 2019 21:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15A7D120120 for <>; Thu, 18 Apr 2019 14:29:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.002
X-Spam-Status: No, score=-8.002 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, RCVD_IN_MSPIKE_H2=-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 t4vl5WXIYeJ7 for <>; Thu, 18 Apr 2019 14:29:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 767A2120046 for <>; Thu, 18 Apr 2019 14:29:46 -0700 (PDT)
Date: Thu, 18 Apr 2019 14:29:45 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1555622985; bh=ZOv6VHhE4JF3psb4D8TFgCD4TYNDX7eAiZESa8e2nr0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=lvHBjA+4BdLZ5lyg5rADaiwiKpejLO3bnlUPkB/6ZXwYM9lOndDD4kzB4K8R+0Wvd icXvqilNK34OCs3Q1Q1jAD7qbXa6GfEiuWSNb7VtFTptgvT76/wM6OOeDqDS86PgHF Soy2kDUn7j61CTGu8EYOq84xVZfijBZKelxcHcW0=
From: Mike Bishop <>
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_5cb8ec49a008d_bf83f88c04cd96031161b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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, 18 Apr 2019 21:29:48 -0000

MikeBishop approved this pull request.

Other than thinking our enforcement guidance should be a bit stronger, I think this is okay.  It expresses the correct principles.

 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 cannot 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 treat a violation of remembered limits as a connection error of an

A server SHOULD treat a violation of remembered limits as a connection error of an
Per previous comment, I believe the outcome from Tokyo was to recommend enforcement.  Subsequent discussion has concluded that thorough enforcement might be too heavy-weight, but the specific flow-control approach is simple enough and ought to still be recommended.

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