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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D388B12027E for <>; Thu, 13 Jun 2019 01:43:20 -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 hl0vufvUa25F for <>; Thu, 13 Jun 2019 01:43:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0D4F1200C3 for <>; Thu, 13 Jun 2019 01:43:18 -0700 (PDT)
Date: Thu, 13 Jun 2019 01:43:17 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1560415397; bh=f9s2XOWaS4GwJ3xzeo4bAf0h95EsjgcYlVO8VYFYyo0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ocL0TcpCpZ7tr7GyFUZ9GYs2xg1sMWiM52nDRFp05UuqLKb10NepZyp9mcTqdCwda oekmPstPAXAsREtN9B1KgeLR7tp9wza+pIVQd+Ua9bUs8ddXL6Qy3EJb5e2ixwFcku 4R5f4XzHw9NvCtTL2fdVfkPtMat0yGDjVMcrZqBs=
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_5d020ca556e15_5d83f96fc2cd968498235"; 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:43:21 -0000

> I also do not see why an endpoint need to update the key as frequently as couple of PTOs. Key update exists so that endpoints can replace the keys becoming weak after being used extensively. A key that becomes weak just after couple of PTOs should never be used. 

I agree with that, however, I'm very much in favor of having a clear-cut definition, instead of second-guessing what the peer's view of the PTO might be).

> I think what you are missing is "endpoint SHOULD retain old keys for a period of no more than three times the PTO" (quoting from section 6). As you can see, the current text already effectively refuses updates more frequent than every 3 PTO. Hence my argument that this is an editorial change.

This sets a **maximum** time on how long keys should be kept. I don't see how this would impose a limit on the frequency at all.

To the contrary, we say that as soon as you receive a packet with the new key phase, you immediately update your keys:
> A receiving endpoint detects an update when the KEY_PHASE bit does not match what it is expecting. It creates a new secret [...] and the corresponding read key and IV using the KDF function provided by TLS.

The spec goes on to clarify that IF you want to limit the number of keys, you drop **the old keys**:
> Endpoints MAY limit the number of keys they retain to two sets for removing packet protection and one set for protecting packets. Older keys can be discarded.

This leads to the risk that packets are dropped **in the case of significant reordering**. Every time this section talks about packet loss, it's always in the case of reordering.

> I think that this interpretation is incorrect; we already have the following in the spec: "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".

I think we have this text because we want to guarantee optimal performance on connections that experience significant amounts of reordering, and waiting for 3 PTOs is a good way to ensure that all old packets are actually received.

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