Re: [quicwg/base-drafts] Receiver's behavior on key update (#2791)

Kazuho Oku <> Wed, 19 June 2019 04:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4E21120443 for <>; Tue, 18 Jun 2019 21:28:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.008
X-Spam-Status: No, score=-8.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_HIGH=-0.01] 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 8bS_27DJJiGx for <>; Tue, 18 Jun 2019 21:28:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A143312018D for <>; Tue, 18 Jun 2019 21:28:31 -0700 (PDT)
Date: Tue, 18 Jun 2019 21:28:30 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1560918510; bh=h+DpZfrmUGJWtYhq3yfBrSUt93FVsxTIHJygN9EPrj0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=UWRCdLJbqXGQxO0SrsvA+qbNRZz3TUwcl8uTLobCH0PA8H63O6/IJNmme3PET44jD 9rGV0z/y5W0/5/VD4vqgK820YhFBk9gVdvDGHCTZYbktgWGtvWNeNsMn3reOu0h/EC y1vPR9BmyMd9ftSRKmgYyxrv5yi88i5ExaeIstBA=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2791/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Receiver's behavior on key update (#2791)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d09b9ee76f29_cc53fae676cd96431283b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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, 19 Jun 2019 04:28:36 -0000

@DavidSchinazi Thank you for the suggestions.

> the MUST stems from avoiding an attacker messing with the KEY_PHASE bit, not from out of order packets.

Yes. An endpoint should not calculate the next receive key whenever it receives a packet with a header claiming that it uses the next key phase, meaning that it needs to cache the next receive key. That leads us to "MUST at least two during a key update."

> An endpoint SHOULD retain a third receive key (the "past" key) so that it can unprotect older packets that arrive out-of-order.

While I like your suggested text for clarifying better how the keys are generated / dropped, this sounds like a new requirement. I think it's unnecessary (and also would oppose to introducing such a requirement).

Therefore, while incorporating the suggested text, I've instead went on to clarify how a 2-key design should replace the "past" key with the "future" key. Also, Instead of naming the three keys, I've changed the text to refer to the key phases using terms "current", "next", "previous", and to talk about their corresponding keys.


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