Re: Key updates

Kazuho Oku <> Tue, 07 August 2018 04:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F58F130E5D for <>; Mon, 6 Aug 2018 21:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x3jODOm7GZVK for <>; Mon, 6 Aug 2018 21:58:56 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 67BB8130E2C for <>; Mon, 6 Aug 2018 21:58:55 -0700 (PDT)
Received: by with SMTP id w16-v6so12336712ljh.12 for <>; Mon, 06 Aug 2018 21:58:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=73h9z9/nxtf+Qie1S4Ziqhua60NBTAM+AFMYBIz/8G4=; b=d83EBtEB+RgXy9dqVnlHK+DS5ZzoRCYT0Tpt5zO7u2ywioAvkj8nscXLlKrEcVNzyM 9kAX10uCrRPabchJeZPWlSu6/JJlwNZZD5rqyi2laFiQ2iVl3Z2pOlcvlLhkTRLZR9FD tMh7Ui2PNyRbpOyDh/MqscAbYzmLYgNmLADChGdEkNZ8I+d0jtnNWPT16BVWL1iT8qIF p7CGxQbIgNxNc7pUeKSORIdgl0vf42vAbpE0TNI80rQC+7hNRdkcdCwN5BeajESgsuJM 4xSn3uo+t2WoOxrcKF3l3UiQ289qksxhxhvbOWM+6qL4bkjX1jSM5nzROx08128e+j48 tvfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=73h9z9/nxtf+Qie1S4Ziqhua60NBTAM+AFMYBIz/8G4=; b=jW/FdYT1/9+w9RUt8vRT7tI8YvGV7XoIFrPIuTRV8xED/mM0fgrvKzXX2/siZW+naP dog5mhTGKWoIWFDwQnONal13LbalBWrW5brI0LW6ieSdKryAwxoy5fz+X0hkoi98yWU/ HDd22lVdCdAPGYTXRs0JlSGw5r7ZzG2ekmzsSk7ECy9LuY4/S8Ed9v4FR5vO+cNR7gOK eG3CB5l9nNX8SZAzdS9R/F8v/qsBJE0ledut9uceoPPGcRmWZi2SAmzcPQYpgw8c/+Co UwT+lzMw0hLXSLgKJ4XofTEJKC9bXb5VlnFaUwQzR6eY79gnpQA9h6AmepqJezaJUooE 526Q==
X-Gm-Message-State: AOUpUlEgwwEJTw5m2LNddhOdQIjduYoMvqoHxNuMMajT86I46iH2varn eEze5HsWTJ0nl1yvSl2rq+GmgjSJkrnCAGlz448=
X-Google-Smtp-Source: AAOMgpdjHIxObLmzi1sdRGCJ/03lBmgqCDjyjWP9tUHIe0MmC3Xg+av2+54eh5S5EqUqS3Z9Uf4FFV2E4BmmAvD5Zrc=
X-Received: by 2002:a2e:2e02:: with SMTP id u2-v6mr15094538lju.77.1533617933615; Mon, 06 Aug 2018 21:58:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Mon, 6 Aug 2018 21:58:52 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Kazuho Oku <>
Date: Tue, 7 Aug 2018 13:58:52 +0900
Message-ID: <>
Subject: Re: Key updates
To: Martin Thomson <>
Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <>, 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: Tue, 07 Aug 2018 04:58:58 -0000

2018-08-06 18:31 GMT+09:00 Martin Thomson <>:
> On Mon, 6 Aug. 2018, 19:22 Mikkel Fahnøe Jørgensen, <>
> wrote:
>> On the last part: using a longer packet number - that would create an
>> observable signal similar to an unencrypted key-phase bit because many
>> packets would tend to have similar sizes, then suddenly spike a few bytes in
>> length.
> The size of a packet number is hidden. Given that most packets are full
> sized, the only effect on those would be less available space for payload.
> ACK packets would increase in size by a couple of octets, which could be
> masked easily and cheaply if necessary.
>> Key phase could also be tied to connection id, and perhaps some
>> consideration should be given to a possible multi-path design before opting
>> for the more complex solution.
> 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.

The other issue with tying key phase to connection ID is that such
design would not allow key update to happen when a zero-length
connection ID is used.

We allow the use of zero-length connection IDs, and I'd assume that it
would be fairly popular for the client-side. I think that we would
prefer such endpoints to have the ability to update the keys as well.

>> As I understand it, the commit option still requires synchronised key
>> updates in both directions. How about one-sided key updates?
> The option I describe doesn't require that both sides update at the same
> time, not do endpoints need to update in lock-step (they can require
> reciprocal updates, but that is discretionary).
>> On 6 August 2018 at 07.56.18, Martin Thomson (
>> wrote:
>> One of the open items out of the design team work was the interaction
>> between TLS and key updates. As you might know, TLS key updates are
>> synchronous, which works well in TCP, but less well in QUIC, where you
>> need at least two active keys for reception around a key change.
>> As it is, I think that there are two serious options:
>> 1. Use KEY_PHASE to signal a change. This requires that both
>> endpoints are loosely synchronized, which disadvantages asymmetric
>> data exchanges.
>> 2. Use a prepare-commit style. DTLS does this by having each peer
>> send a KeyUpdate message, then requiring that to be acknowledged
>> before they can switch to the new epoch. QUIC could do the same. The
>> change is still signaled in the key phase bit, but only after this
>> signaling exchange.
>> The weakness of the first option is that packets marked with a change
>> of key phase trigger trial decryption. And it requires synchronized
>> changes, where if one endpoint moves to epoch N (epoch == encryption
>> level with fewer characters to type), then the other has to follow
>> before either can move to epoch N+1. The second has more moving
>> parts, but avoids both of these problems.
>> I tend to think that the second is a better design on balance, if only
>> to dispense with the trial decryption, which we've managed to avoid in
>> every other case thus far. The complication might also present some
>> opportunities, which I will explain below, but that's a secondary
>> concern.
>> If we want to use this signaling method, we need to decide who drives
>> key updating, TLS or QUIC:
>> TLS: The DTLS design might work in QUIC, but with the KeyUpdate
>> message hidden in an opaque CRYPTO frame, it could be a little tricky
>> to manage properly. If we let TLS drive the key update, then it will
>> send a KeyUpdate message in a CRYPTO frame and inform QUIC of the
>> change in sending keys. From here, QUIC can keep using old keys until
>> all CRYPTO frames from that epoch are acknowledged. The receiver will
>> inform QUIC of new receive keys when it receives KeyUpdate, which can
>> be installed.
>> QUIC: Here we define a new frame type (KEY_UPDATE, say) that QUIC
>> sends when it wants to update keys. When this is acknowledged, new
>> keys can be installed and used for sending. A new API is needed to
>> TLS to support cranking the key schedule forward. Invoking that API
>> would lead to TLS signaling the availability of new keys. The receive
>> side isn't any different from the TLS option. If this was to have
>> parity with TLS, this would probably need to be two frame types so
>> that a unilateral update could be distinguished from an update that
>> includes a request for a mutual update.
>> In both cases, QUIC will install new receive keys, but retain old
>> receive keys so that it can deal with reordering. A few round trips,
>> an RTO, 2MSL, or whatever we decide for the handshake is probably
>> fine. Sending keys can be discarded immediately.
>> The advantage of having TLS drive is that it uses the same machinery
>> we have for the handshake. And there is no disparity between what TLS
>> and QUIC understand to be current: when TLS wants to send something (a
>> NewSessionTicket message for example), then it asks for an epoch that
>> matches what QUIC is using.
>> The disadvantage of using TLS is that there are more moving parts
>> involved. It fits the rules we have for the handshake neatly: for
>> instance, the CRYPTO frame would be retransmitted using the strict
>> encryption-level rules, reusing that code from the handshake. But
>> those rules aren't really necessary given that the rules for a
>> KEY_UPDATE easily have the same effect.
>> My inclination here is to have TLS drive this. The additional
>> complexity seems to be manageable in the sense that it uses mechanisms
>> that should already exist for the handshake. I also don't think that
>> a new API for this feature is a good way to ensure that it is used.
>> Those who are implementing, I know that key updates are often a long
>> way down the list of priorities, but has anyone spent time considering
>> the options here? (I personally implemented key updates for TLS, but
>> I still haven't managed to find time to do it for DTLS, which might
>> say something...)
>> --
>> Addendum: Optional Key Phase ?
>> One of the nice things about either prepare-commit design is that it
>> opens a new option for how we use bits in headers. If there is a
>> concern about spending a bit on every packet for the key phase (a
>> whole bit!), we could design an encoding that only included the key
>> phase if a longer packet number encoding was in use.
>> The idea would be that you could use the longer packet number encoding
>> while you have a key update outstanding, so that the key phase was
>> available for the entirety of the changeover. Once packets with the
>> new epoch were acknowledged, you could switch back to a shorter
>> encoding that didn't include a key phase. The receiver would switch
>> to expecting the new epoch after receiving the first packet in the new
>> epoch.
>> That's a saving that might allow endpoints to use the shortest packet
>> number encoding in more cases. Of course, the header design is
>> already complex enough, so maybe we don't actually *want* more options
>> to consider there :)

Kazuho Oku