Re: Key updates

Martin Thomson <> Mon, 06 August 2018 09:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50DDF130EB9 for <>; Mon, 6 Aug 2018 02:52:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JeMjRVnEnaSE for <>; Mon, 6 Aug 2018 02:52:35 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C637F130DE2 for <>; Mon, 6 Aug 2018 02:52:34 -0700 (PDT)
Received: by with SMTP id k12-v6so21056694oiw.8 for <>; Mon, 06 Aug 2018 02:52:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ug6YJpBePYU3s7oL0aCl3AFgD7e6sNpoCWfFQ7osE8Q=; b=TG6MliUHUSZ1OeDGdaspOx+2HYsCC1EQ6vyXjPpXvQOcZ3HBvc1bays+yjdMjTSjpW aMSgkH7pK1eHfiiXvolC9wgYPUEE3ZYcwsTtbAciuQKYAXK2HA7+zZhbwJJoyrRVFXqN PJXKQW2bUpNa6D4bMa5EiBLzlmQ8NXH0XR6pVljFFG8sp/GG9/eHr+C23uTKNR7SBnvj YbLw1Xk8nQYzdaAWZOO5TcZYhhvuC5dc0ZC/PkVCiWKKsUU6tEJiKQYlV1IGwaB355Qp ZXBdYchxLzqpm9P5WFwvbacdZg7m/Aa/1yVHhY99xxRlXE/PKEHTkWn+4XBzaKdRmFFT BVZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ug6YJpBePYU3s7oL0aCl3AFgD7e6sNpoCWfFQ7osE8Q=; b=YCIEdDmBJVgclP1AyHlZP7vSD7dEKBc/c+WsdA5i8z8sl1qe4RIgcYarIS7lS2rbQm FIwjP7bZdwi8+rY6eFotwBE3UU5uzflPI/UYboVPs2b2uouRljA8k4py8oH5QdClT/Vq 5MMzZNo50dA6oF7eK0UXfWF4KA0mIiGvQVZSFGd33oXEUupuoZMmePa/3YgMJ63+jF3d TCu/n99sjYXjzdAihOCcYUMG2Gg6aVNkoVRWrCImrTf6er7K/rhCXPN/R2BNeP30a9go Q7C8ubJW1GtykGp8yDdDbM0q2d6SwxYe2GHiDQzr2810zCWL0RNro88TxPYM2AtpUBfo iFtw==
X-Gm-Message-State: AOUpUlFQSGbDOLRtALFxfw9bLP6D0adHfpzGsoumj5c9rq13esr4xYIq E2lP95ue+nP40fl7DZqDjdsFC7Cr7u8SCt6/da1tyBRY
X-Google-Smtp-Source: AAOMgpeHp5w4aC4x2V2C0L8D4KYUoiYo+vCNxC/TJ5lhF/o/480NH5tSYU25vkVKNA9pOkD7vyKA0OjtWvkIbTfhUOQ=
X-Received: by 2002:aca:5841:: with SMTP id m62-v6mr14842132oib.346.1533549154032; Mon, 06 Aug 2018 02:52:34 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Martin Thomson <>
Date: Mon, 6 Aug 2018 19:52:24 +1000
Message-ID: <>
Subject: Re: Key updates
To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <>
Cc: QUIC WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Aug 2018 09:52:36 -0000

On Mon, Aug 6, 2018 at 7:44 PM Mikkel Fahnøe Jørgensen
<> wrote:
>> This is definitely an option I have considered. If you have a workable design, I would be interested. I couldn't reconcile the desired rates of updates. Connection IDs are needed in spikes, where the rate for key updates is more measured.
> I believe the current consensus is to have an ordered set of connections ID’s. If that were not the case, or if there were two sets, then some connection ID’s could be associated with a key update. If running out of key update ID’s, a new such ID would be requested. This is somewhat similar to the commit based option.

The current direction seems to be toward a bag of connection IDs,
without ordering.  I considered attaching an epoch to
NEW_CONNECTION_ID and having updates coupled to key changes, which
could work if you were willing to couple changes in that way.  The
problem there is twofold:  the provider of connection IDs is in
entirely control over when updates happen (you can't ever update
yourself unilaterally), and not all connections have a connection ID
in the relevant direction.  The former is annoying and probably
manageable, the latter is a real deal breaker.

>> ACK packets would increase in size by a couple of octets, which could be masked easily and cheaply if necessary.
> I’d challenge that, especially in the cases where it matters most: long running mobility applications. For example a car management system that uploads battery and other operational statistics, geofencing applications, or chat applications used by train commuters.

Are you suggesting that these applications have fixed size payloads
such that the change to a longer packet number would be noticeable.
That's might be true, but sending a TLS KeyUpdate message or
KEY_UPDATE frame would also change the size of packets in a fairly
obvious fashion if that were the case (many of these applications have
a predictable send rate) as well.  If there is an occasional increase
in rate, both in terms of number of packets and size, then yes, that
could reveal that a key update happened.  If that happens across a
change of path, then yes, there is a linkability exposure.  Given how
packet rates are low on these applications, it might be that key
updates could be disabled for those applications if this is a concern.
As it is, this is far better than a cleartext KEY_PHASE bit, which is
a great correlator.