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

Kazuho Oku <> Wed, 19 June 2019 08:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BC2D120194 for <>; Wed, 19 Jun 2019 01:16:14 -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 FQTi5n0g8k5J for <>; Wed, 19 Jun 2019 01:16:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B36EB120073 for <>; Wed, 19 Jun 2019 01:16:12 -0700 (PDT)
Date: Wed, 19 Jun 2019 01:16:11 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1560932171; bh=fgnlKUw+5FgQGiyqJY/mrJQ7Rt5pgaGfkTfyAZwLu+k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=bpyIMA8nSNnYmvImP0UCyT5FL3s/VyR+wS6F2ZTSrW+e/nYXTrKbJesK/xnPAA4D9 kuegB8/w/jUP6ZR6L9RrfhFBucrPJpm7F+pDoBcZqS0h5lWIETXyWW0VFGlTHNONrz /exEerC5TAxOff7mUbrddEMqDMX1uJWXkGTBzT4Y=
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_5d09ef4b8550d_58bf3fb307ecd96c910d9"; 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 08:16:15 -0000

@mikkelfj Thank you for the suggestions.

> An endpoint SHOULD compute the secret and related receive and send keys of the next key phase ahead of time

> SHOULD transitionally maintain an older key to deal with late arriving packets for a duration of 3 PTO after switching to a new key phase.

It is my understanding that if we should make these non-editorial changes is an open issue (see #2792).

> (EDITORIAL NOTE: I'm struggling with when a key is fully retired and in violation because it is always possible that an earlier packet is received after a key switch which also carries the new key phase. You could formulate something but it gets complicated).

An endpoint should not call it a violation when it receives a packet carrying an awfully outdated key phase, because such behavior would allow an on-path attacker to disrupt a connection, by buffering a and injecting a very old packet. That also means that there's no reason to define when an old key is dropped.

> Maybe we can just use "successfully unprotect" instead of decrypt and authenticate. Or perhaps it is enough to authenticate without decrypting. Noting that these are parallel and separate steps in GCM that can be processed separately.

It is true that we use "decrypt and authenticate" as a synonym of "unprotect." I can see that it might be confusing. OTOH, we should never allow decryption or authentication as a separate operation, because that would lead to timing attacks.

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