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

David Schinazi <> Tue, 18 June 2019 17:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC0AD12001E for <>; Tue, 18 Jun 2019 10:31:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.009
X-Spam-Status: No, score=-8.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 JLGB73GcNr1n for <>; Tue, 18 Jun 2019 10:31:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2C091200C4 for <>; Tue, 18 Jun 2019 10:31:50 -0700 (PDT)
Date: Tue, 18 Jun 2019 10:31:49 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1560879109; bh=kf/gf1XCqym4DQ8NKavy1OF0FTtS8Vil/8U4Ol0eaCc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=zHQ6Dfs0hT3T/KFbRcjQA52rqpTCuIAHBJZy2hmBgXEjhB4FWuluvvk+wJghRuI/r IJ7YPiMc/P+PYcU4nWmzuS58tNh3qZfZjxvGzoGqzk9J/2ID5baGWPsd94OJMPzBub jj2rpqXt7O5NLvZIWobzIJDjFnkL0uLqyIkewuPA=
From: David Schinazi <>
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_5d0920055afaa_15ba3f9441acd9649421c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: DavidSchinazi
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, 18 Jun 2019 17:31:53 -0000

Thanks @kazuho. I still think we can improve this, the MUST stems from avoiding an attacker messing with the KEY_PHASE bit, not from out of order packets. Perhaps something like the following?

While only one send key is used at a time, an endpoint MUST retain at least two
receive keys (the "current" key and "future" key) during a key update to prevent
attackers from triggering key updates. An endpoint SHOULD retain a third
receive key (the "past" key) so that it can unprotect older packets that arrive

Packets received with the current active key phase are unprotected using the
"current" key. When a packet arrives with the opposite key phase, an endpoint
determines which receive key to use by tracking the lowest packet number
among the packets received with the currently active key phase.  If a
packet is received that has a different KEY_PHASE bit and a lower packet number
than this value, the endpoint uses the "past" receive key for unprotecting the
packet, if that key is available.  If the packet has a higher packet number, the
endpoint derives the "future" receive key by calculating the next secret
(see Section 7.2 of {{!TLS13}}), the corresponding read key and IV using the KDF
function provided by TLS.  The header protection key is not updated.

If the packet can be decrypted and authenticated using the "future" receive key
and IV, then the endpoint switches to the next key phase, installs the "current"
key as its "past" key, and installs the "future" key as its "current" key.  The
endpoint also updates its send key to match its "current" receive key. The next
packet sent by the endpoint MUST then use the new send key.  Once an
endpoint has sent a packet encrypted with a given key phase, it MUST NOT
send a packet encrypted with an older key phase.

Updating keys multiple times rapidly can cause packets to be effectively lost if
packets are significantly reordered.  Therefore, an endpoint SHOULD NOT initiate
a key update for some time after it has last updated keys; the RECOMMENDED time
period is three times the PTO.  This avoids valid reordered packets being
dropped by the peer as a result of the peer discarding older keys.

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