Re: [quicwg/base-drafts] Clarify the side-effect of frequent key updates (#2788)

Marten Seemann <> Thu, 13 June 2019 08:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2F391201BB for <>; Thu, 13 Jun 2019 01: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 B-bobrkHdNMt for <>; Thu, 13 Jun 2019 01:08:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 087531200F4 for <>; Thu, 13 Jun 2019 01:08:08 -0700 (PDT)
Date: Thu, 13 Jun 2019 01:08:06 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1560413286; bh=uvTf5cseVmNdNVC8RI0Ed/xSbti0Q4zjJ+69DtcO0Qc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=NhtFiKqwIwu1c4iqRjsfQOKS5/6ZKVartSJgcH/BWnYWSj/7AbawuGwkbGoiH41Vg cBc5bGiHVmEa73QIVHIvZq23+i1M7izNPDL/zd4ftNZq+H8c5mYK+28gX0f45C9piw 811Ryw4Idqr5hP/lETObqLzRC05KXWimd3JEh9hY=
From: Marten Seemann <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2788/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Clarify the side-effect of frequent key updates (#2788)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d020466b52d0_78d83f96f0ecd9681971548"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
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: Thu, 13 Jun 2019 08:08:10 -0000

I disagree that this is editorial an PR. 

As I understand, in the current text we're
1. Limiting the the frequency of key updates to avoid the deadlock in the case of frequent key updates (#2214). This is achieved by requiring a peer to not update keys to N+1 before receiving an acknowledgement for a packet sent at key phase N (which effectively limits key updates to no more than once per RTT).
1. For crypto hygienic reasons (and to limit memory consumption), we're only keeping old keys alive for a maximum of 3 PTOs, and dropping them afterwards.
1. If key updates are performed more frequently than once per 3 PTOs, endpoints MAY drop old keys sooner (again, in order to limit memory consumption). Note that this leads to (effective) packet loss if there's sufficient reordering of packets encrypted with the old keys. However, if there's no reordering, no packets are lost.

This PR changes the text such that a peer could effectively refuse to update to the new keys for a period of 3 PTO, thereby inducing massive packet loss on all packets encrypted with the new key phase, even in the absence of packet reordering.

In my opinion, this change is therefore not editorial, but a design change. 
Furthermore, I'm also not convinced that this is the right way to go. The current text has the nice property that there's a very clear definition when a key update is allowed: as soon as you receive an acknowledgment for the current key phase. According to this PR, this clear definition is replaced by saying that a subsequent key update shouldn't happen within 3 PTOs. The problem is that the PTO is a local value, and peers might disagree about the precise value at any given time. Therefore, there's no clear point in time when a key update could be performed safely (i.e. without risking that the peer refuses to update keys).

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