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

Kazuho Oku <> Tue, 18 June 2019 00:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E087120336 for <>; Mon, 17 Jun 2019 17:08:09 -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 SrwPqCf1xEnW for <>; Mon, 17 Jun 2019 17:08:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 16922120183 for <>; Mon, 17 Jun 2019 17:08:07 -0700 (PDT)
Date: Mon, 17 Jun 2019 17:08:05 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1560816485; bh=Of/C6sYlcw/smQA/uESMo85Sz/Q73MEcJcz8zHNxIgA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=coa0r8gVsQlYwyOBm6bbrCgn7x8zEDPHxj7hvsPda107YwPI3klVJRZ7hchXmiAZc Hgxr/j24KoowbUMf2wXfLmkpfnjanX+sOOzPBpm1aNo3HQdhN440/6d80ZE2Nil9U7 zvAvJdjg6NxftWirYg7EcFz50Fh4l82b381bsLEY=
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_5d082b65e1a23_549a3ff39b0cd96413151"; 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: Tue, 18 Jun 2019 00:08:09 -0000

@DavidSchinazi Thank you for your comments. As I am uncertain what the correct approach is, I have so far tried to keep this PR a clarification of what's already written.

#2792 is the issue that discusses the problem in the current algorithm.

> The algorithm you describe actually uses 3 receive keys: you have the old one, the current one, and the new one. The new algorithm only overwrites the old keys with the new ones if decryption succeeds, which requires keeping 3 keys in memory while you're decrypting. The minimal algorithm immediately overwrites the old key when receiving the new packet, and that only requires keeping two keys in memory.

Current text states that a new key is computed every time when a received packet specifies an epoch for which a key has not been installed. This process is repeated until packet unprotection using that key succeeds and the key gets installed. Quoting from the current text: _"A receiving endpoint detects an update when the KEY_PHASE bit does not match what it is expecting. It creates a new secret (see Section 7.2 of [TLS13]) and the corresponding read key and IV using the KDF function provided by TLS."_

So at the moment, the text only requires an endpoint to retain 2 keys in state, and that is in line with "MAY limit to 2 keys." However, such algorithm does have side channel vulnerability, hence we need to discuss how to fix the issue (see #2792).

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