Re: [quicwg/base-drafts] Rewrite key update section (#3050)

Jana Iyengar <> Fri, 01 November 2019 04:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 585881200C5 for <>; Thu, 31 Oct 2019 21:06:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 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, SPF_HELO_NONE=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 nqMIQ3JMyZ-g for <>; Thu, 31 Oct 2019 21:06:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0AA3712006D for <>; Thu, 31 Oct 2019 21:06:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5897A6A0BE9 for <>; Thu, 31 Oct 2019 21:06:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1572581191; bh=V3c+Wp8qq3ufJ+VT0LqAjmvdJGqIVXNsUjSMZhKCnuo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=TuDWKXEbutK5y3T6/WsBkemE28RE/Ksvl0W2q5Mqy0oBn7XrjxcL3L7mJqfRRO+Tr cZygdu3102w+GRXACkyYHFD6t6+wluN+Xsra32Q1Bj1Vu/XGA5WhSe/y27MiQz6RDB axBH1fAfyOIeoa/FzgMdp7hK4iUjZK7POuJO6FXo=
Date: Thu, 31 Oct 2019 21:06:31 -0700
From: Jana Iyengar <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3050/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Rewrite key update section (#3050)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dbbaf4749f8e_7e583f820e8cd960487262"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
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: Fri, 01 Nov 2019 04:06:34 -0000

janaiyengar approved this pull request.

A few nits. I've asked @kazuho if he could take another look as well.

> +corresponding key and IV are created from that secret as defined in
+{{protection-keys}}.  The header protection key is not updated.
+For example, to update write keys with TLS 1.3, HKDF-Expand-Label is used as:
+secret_<n+1> = HKDF-Expand-Label(secret_<n>, "quic ku",
+                                 "", Hash.length)
+The endpoint toggles the value of the Key Phase bit and uses the updated key and
+IV to protect all subsequent packets.
+An endpoint MUST NOT initiate a key update prior to having received an
+acknowledgment for a packet that it sent protected with keys from the current
+key phase.  This ensures that keys are available to both peers before another

key phase.  This ensures that keys are available to both peers before another key update

> +receiving packets.  These keys will be needed to process packets the peer sends
+after updating.
+An endpoint SHOULD retain old keys so that packets sent by its peer prior to
+receiving the key update can be processed.  Discarding old keys too early can
+cause delayed packets to be discarded.  Discarding packets will be interpreted
+as packet loss by the peer and could adversely affect performance.
+## Responding to a Key Update
+A peer is permitted to initiate a key update after receiving an acknowledgement
+of a packet in the current key phase.  If a packet is received with a key phase
+that differs from the value the endpoint used to protect the last packet it
+sent, the endpoint uses the next packet protection keys for reading and the
+corresponding key and IV; see {{receive-key-generation}} for considerations

It might be kinder to the reader if you could split this 3-line sentence into two sentences.

> +its peer has updated keys twice without awaiting confirmation.  An endpoint MAY
+treat consecutive key updates as a connection error of type KEY_UPDATE_ERROR.
+An endpoint that receives an acknowledgement that is carried in a packet
+protected with old keys where any acknowledged packet was protected with newer
+keys MAY treat that as a connection error of type KEY_UPDATE_ERROR.  This
+indicates that a peer has received and acknowledged a packet that initiates a
+key update, but has not updated keys in response.
+## Timing of Receive Key Generation {#receive-key-generation}
+Endpoints responding to an apparent key update MUST NOT generate a timing
+side-channel signal that might indicate that the Key Phase bit was invalid (see
+{{header-protect-analysis}}).  Endpoints can use dummy packet protection keys in
+place of discarded keys when key updates are not yet permitted; using dummy keys

place of discarded keys when key updates are not yet permitted. Using dummy keys

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