Re: Key updates

Martin Thomson <> Tue, 07 August 2018 05:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C93C130E6F for <>; Mon, 6 Aug 2018 22:15:37 -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 vvbZSLh5xyAY for <>; Mon, 6 Aug 2018 22:15: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 C344E130DF2 for <>; Mon, 6 Aug 2018 22:15:35 -0700 (PDT)
Received: by with SMTP id b16-v6so12924540oic.9 for <>; Mon, 06 Aug 2018 22:15:35 -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; bh=Y5WgzPvQxrE3t3YO7XnFvCiN9E7obc43RaeAbu5l9cE=; b=M2ecf78QKEJj0Hsk2+BDbfWPPRZtpNJS7O4oV4H5rxX/tr0hJyBfO/2xnD/rAwuwIc Wr889stbtRAL3PTy07az9J9lyj9dst3/uzlh3xFgKqe80HUuLiR/Ovf954dR3DqtsxCj 8RBpFKB0pClYT0b3pwi8yUEGFca6oSxPbOAs/IOV9L6OluYj7vjBpLKrR6DkYLbFAO/q rTDyffSIQDQyz2oZEx085d+8ejNs+3Xnhkji01nTJ7WLFX5sNBsJG+I+++3acMMAVMKa M7/VjG0dgrJ/BP4Vmdg5/4eP/y17yeZQT0CFRCb0LGtBNy9/wr1ZSCmr5wPr1Lev8PgY nmrA==
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; bh=Y5WgzPvQxrE3t3YO7XnFvCiN9E7obc43RaeAbu5l9cE=; b=RVJvDpAJb5QqMIqchRmqZFcrLbZcvuE27/4SmnVudq4rbir4XFh2rzVQMm7j3/oB3X 3ok/2TsZv2/dRKyIUJMIgbRi4lvtGAzqC2SZsyofRteOfs2ip7Mj5t2WlIPNdC/YeAEL ICX7KYgqaBbnqgIOBDNw2OYJMSiciQqTb0Gq/wl2tY/K5DvBIow3h6DtYfr0YaNXRfsw D5ot2bhSj4ozbepYMJ+LVBYp+KKjEKt4FFvM65z0PpKOV8tSgMwuuE4ROIgmz4OpDlB8 s6t+VT4Ck1lU9JeSgdUBuu0p0pG5m+Oy5B9fF6vOc/DT7dypTziINasmIRGHJQI2T+zc mXdw==
X-Gm-Message-State: AOUpUlGTLUPCKiSJMbHyxlKafXpUyWgDNTRhToqWGVZ2zHwNVIB4cGuN l7qx2/p5A73KKhroRC0k6LjMFLMvQBOYdz/5unbFOw==
X-Google-Smtp-Source: AAOMgpdrTRnXaBFAt1fDNrfeVVr+jMZutWE5sdn0NvxvuPJaia0r8JMv6PPfXM67zOjvvuAsR5+jubGrWPvSKUJvfs8=
X-Received: by 2002:aca:100f:: with SMTP id 15-v6mr18537579oiq.110.1533618934921; Mon, 06 Aug 2018 22:15:34 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Martin Thomson <>
Date: Tue, 7 Aug 2018 15:15:24 +1000
Message-ID: <>
Subject: Re: Key updates
To: Kazuho Oku <>
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 05:15:37 -0000

On Tue, Aug 7, 2018 at 2:55 PM Kazuho Oku <> wrote:
> I do not think that the current mechanism requires trial decryption.
> IIUC, the endpoints are not allowed to start sending packets at epoch
> N+1 until they see peers acknowledging packets that were sent in epoch
> N. That means that an endpoint only needs to have at most 2 keys (for
> epoch N+1 and N). The epoch (either N or N+1) can be recovered from
> the KEY_PHASE bit and there is no need for trial decryption.
> Am I missing something?

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.  A
little reordering will cause them to be interpreted as N+1 instead
(because they arrive after packets at N and we only have one bit of

So if you want to avoid loss spikes around rekeying, you have to do a
little trial decryption at that point.

Also, the way you ratchet forward is to observe a bit flip, at which
point you decrypt with N+1.  If that works, then you do something.
It's not quite trial decryption in the sense that you only try one
key, but - having implemented it - it's a little annoying to get

> I am not sure if adding a way to signal the receipt of ACK for a
> particular TLS message from QUIC to TLS stack is worth the cost. We do
> not have that kind of mechanism. I am scared that such mechanism could
> become very complex, considering the fact that the QUIC stack can
> split TLS handshake in any way that it would like.
> Or are you suggesting a mechanism other than what is defined in DTLS?

It's pretty close that in DTLS.  Here's what I imagined would work:

You let TLS send its KeyUpdate, which gets bundled into a CRYPTO
frame.  TLS moves to the new epoch, and advertises the availability of
new keys.  However, you continue to send in the old epoch until you
have flushed all pending CRYPTO data from the old epoch (i.e., the
CRYPTO frame has all been acknowledged).  All other processing stays
the same: CRYPTO frames are always sent using the same keys, even on
retransmission, new TLS messages would be sent in the new epoch, and
ACK frames would need to send using the epoch of the packets they

The reason we don't have problems with the handshake is that we *know*
that the peer has keys for the new epoch.  Otherwise we would have to
do the same thing.  There, following these rules would mean sending in
the clear, which isn't smart.  Here, it's just a key update.