Re: Key updates

Kazuho Oku <> Tue, 07 August 2018 07:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D1E91130DEB for <>; Tue, 7 Aug 2018 00:01: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 ZammcKh7qFfg for <>; Tue, 7 Aug 2018 00:01:35 -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 8F5EB130D7A for <>; Tue, 7 Aug 2018 00:01:34 -0700 (PDT)
Received: by with SMTP id j19-v6so12547059ljc.7 for <>; Tue, 07 Aug 2018 00:01:34 -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; bh=uEVZIUPFHsqXWHvrQMQdKRmqTnjGeqIa3RHqR9/QDSU=; b=hmBZVmljBTi/0bOGEMgq1gt5f61t45wYe+CIrlPfonuAmB+QkICLKBg6oAVxLd5j3U yuCYUD0YIFrp4oz34gTSjvhy2FgBnKIbPWmGJAiVHcZzg/SyZvg62VQTDZkWvV129mJt 2AI/37JEzdsfAYE7bDLYBkba6Jl/8Es29zCqU1txEUDCppMo0qWeLly2TMNxnUbolAC9 +LrsB3ue/B6HHuGO881UA4B+b5fX1YTaq8p+xZQFr/JDpdYZw7EV6Ri1xQX1BF4udHnF oSKT3Fq3dyPd5dVCfhGs9uygukchd/GMEjsigdv2S15gFRIc+YXP16RxDB6gqF/QUWUC 0CbA==
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; bh=uEVZIUPFHsqXWHvrQMQdKRmqTnjGeqIa3RHqR9/QDSU=; b=cb9Z+zHChpU13zOPwlBKu6wJR7pxGMzcOhDOI44hqwM76dwVoSb+WBIDYeZLibyGVr 0ukquGZu1AJStLDj4fn4K+ZSEiuMuuGWKCPK84xjI2nWJhgBy3PMAATKNeCsxfvRLaPE IP9vBifbzBPwaj7axBD+Q+AnkEv0Q6vO5c0SdKYMYcpVJsF90T1IgmvQW19091jvAgV7 oaT7zZIKOxKsOYmVhU2UxMOJnFq1hztWODmf/wBJU+JFyGYRZRCu1PVhPrsvl9iw1wg6 5VL3SVMWhR4+1KwetmzitMOGwAaWmOynQzN8BXtgSWoyD5uXql9LTlXvDq3GCIci+rtx mAYA==
X-Gm-Message-State: AOUpUlEHpxN6oedjXhiwutIDWp9VT3YMGDkZR5FfmkNUhXHuvSOBRQl4 MNzKYfQoKCuIbqxa6qBG9uJ86pkImzC+NmELugY=
X-Google-Smtp-Source: AAOMgpfj5PezlxEyFCm1dkFk3/9TgoZM+Jr6IWQuDmhZZQMq6HSMYs5I2ldV9cILEfgpl4+7ihdQmNKbyzpK+/G1sKo=
X-Received: by 2002:a2e:40c:: with SMTP id 12-v6mr15559056lje.146.1533625292819; Tue, 07 Aug 2018 00:01:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Tue, 7 Aug 2018 00:01:32 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Kazuho Oku <>
Date: Tue, 7 Aug 2018 16:01:32 +0900
Message-ID: <>
Subject: Re: Key updates
To: Martin Thomson <>
Cc: QUIC WG <>
Content-Type: text/plain; charset="UTF-8"
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 07:01:37 -0000

2018-08-07 15:37 GMT+09:00 Martin Thomson <>:
> On Tue, Aug 7, 2018 at 4:10 PM Kazuho Oku <> wrote:
>> > There is a problem right now with concurrent updates.  If both peers
>> > bump at the same time, then N-1 packets could still be in flight.
>> I think that we might be having different models in our minds.
>> My view is that, in principle, an endpoint unilaterally updates its
>> epoch that it uses for "sending" packets. An endpoint MUST NOT update
>> the send epoch before it sees an acknowledgement for a packet that was
>> sent encrypting using the current epoch.
>> To implement reciprocal key update, we will also state that, if the
>> send epoch used by the peer becomes greater than the value used by an
>> endpoint, then the endpoint SHOULD increment it's send epoch as well.
>> If we define the rules this way, I would assume that there is not
>> chance of key getting updated twice even in case both the peers decide
>> to update at the same moment.
>> To put it another way, the issue with the reciprocal (D)TLS-style key
>> update is that it is defined as a "request" rather than a state change
>> with idempotency. The rules above is designed as an idempotent state
>> change from N to N+1 that can be implemented by either peer without
>> the fear of double update that will lead to potential loss (unless the
>> endpoints retains more than two keys).
> There is nothing inherently wrong with the current design, but I
> recently realized that there is a corner case that is awkward at best
> without trial decryption, even if you follow those rules.
> A sends N+1
> B sends N followed by N+1 around the same time.
> 0.5 RTT later both receive a packet at N+1, so both update (not
> naturally noticing that the response was a little faster than it
> should have been).

My point is that the issue within the current design is that we
require the endpoint to update if the peer initiates an update.

I am suggesting to change that to "an endpoint updates its epoch if
the peer starts using an epoch that is higher than it uses."

Taking the example,

A sends N+1
B sends N followed by N+1 around the same time
0.5 RTT later both receive a packet at N+1, and they will stay using
N+1, because each of them initiated an update and because the epoch
that one uses is not smaller than the value used by the peer

> A receives the packet from B at N, reordered a little (maybe the N+1
> was a small packet at the tail of a burst).
> A thinks that this is N+2 and discards it.
> Now, this isn't a correctness issue.  But it's annoying.  It drives
> the congestion controller down more than is ideal and adds a bit of
> extra latency for anything depending on the contents of that packet
> (or those packets if there is more than one).
> You fix this by running trial decryption for N and N+2 for a short
> time, or you move to the prepare-commit style of update.
>> I think that the described algorithm will work fine, but I am not sure
>> if I like the fact that it requires the QUIC stack to remember the new
>> encryption key and the fact that a KeyUpdate message has been sent in
>> a CRYPTO frame at certain offset, and switch to the new key when all
>> the data up to that offset is acknowledged.
> The QUIC stack doesn't have to remember anything other than that is
> received new TLS data at epoch N and a key change after that.  The
> rules for transmitting CRYPTO frames at the same encryption level
> ensure that everything works correctly.  Now it has new send keys, but
> the only new rule it needs would be that until all crypto frames for N
> are acknowledged, you can't starting sending on N+1.  I tend to think
> of this as not being a new rule, but instead that there are
> exceptional rules for this during the handshake.
> The rules for receiving are different: you install N+1 for reading
> immediately (discarding N-1 if that is still around).  You can discard
> N+1 on a timer (that can start immediately, I think, based on what I
> worked out for key expiration timers, which I am about to put up as a
> PR).

Kazuho Oku