Re: [TLS] KeyUpdate and unbounded write obligations

Eric Rescorla <> Sun, 28 August 2016 17:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0CE712B050 for <>; Sun, 28 Aug 2016 10:53:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 lwRQpCtTA7UO for <>; Sun, 28 Aug 2016 10:53:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B7C1712B018 for <>; Sun, 28 Aug 2016 10:53:55 -0700 (PDT)
Received: by with SMTP id j12so74902190ywb.2 for <>; Sun, 28 Aug 2016 10:53:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V4EEDUWmnzwW0J9su7aFQI7broCglulO86hLjZVV2A8=; b=pXNIFUCG8+gtndQOON4huZrFJDY3cQXVkVM1gRlcmtOqJcAeb7jZxeXyiLOK8BebSz BcdlZf+Mo8/OXKHV1V0/DakqQeXOdZts1RTyURs4Ee5nSIOufHyqb+GapgIAbAqJjbRl sulqtE6IOvmHZzjzckrUCMGnH7Du7A4CQeLquxdODmmNJy0v+HSo9rXuJ94MidyW5or/ JmIY6/jUL26BgascyFOa62d5MHsz4xPamuZOdMxrKTVK6z61vWA5aA5MiyYo1clxIhFp ANxkoMseHsH22nD2ec8qyn0x5IvKoc1wUxNsiCMVGXkKUWrylYmDHsePF7DZngI2yPeJ y2hQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V4EEDUWmnzwW0J9su7aFQI7broCglulO86hLjZVV2A8=; b=YzTF5ahkqRekGQnccJ9s4JD+JF/rhzDOX7+Pur7gVT3R8VZf4T9mIRhb4LHV8L1wT8 GwMsw/0LP679AvG/YWJHC94SjLILMwFfxnMUrUrxAQNOzfu/E8j5AIvSK+maZ5IxgdrJ dMAYe43b55OuRkUS0HvNO/VLqaat0Xv4Ml5XgNyfpXbgBxizQZhKgGlXEBDJg8Vl/7HS 6ON1CME7Gd6cxk9FXXJCLAPn/NzbmZUtDVccgXGmK8BjYSWplvUgDBmIj2Dnjl361UUE aRak1D5FV/+xkTwwm3jC/hGro1lQ6a7K3EonGHoal+EX3YX6KYF3CRTVqy6p4v3VAmsc 2WFg==
X-Gm-Message-State: AE9vXwPsWZoN9pdrYSm7PvdwtP4XE5G1XC0Oj9r0Yq4fpMDXMKjKvzdFHs0FYvlOX1prQt/NhIgJrcfusL3zWg==
X-Received: by with SMTP id y129mr12174763ywc.107.1472406834962; Sun, 28 Aug 2016 10:53:54 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 28 Aug 2016 10:53:14 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Eric Rescorla <>
Date: Sun, 28 Aug 2016 10:53:14 -0700
Message-ID: <>
To: Keith Winstein <>
Content-Type: multipart/alternative; boundary="001a11492ce85d21f9053b256e06"
Archived-At: <>
Cc: Adam Langley <>, "" <>
Subject: Re: [TLS] KeyUpdate and unbounded write obligations
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 28 Aug 2016 17:53:58 -0000

I'd like to close this discussion if we can.

I'd prefer to keep things as simple as possible here and from that
perspective, I think any indicator from side A to side B that it wants a
key change over and above the KeyUpdate is extra complexity. I do, however,
want to retain the property that one side can ask the other one to rekey
[0]. I believe we can get this by modifying the rule in the spec by treating
a run of KeyUpdates as a single generation.

"Upon receiving a KeyUpdate, the receiver MUST update its receiving
keys. If the receiver has sent any data records since receiving the
last KeyUpdate it MUST also increment its min_send_generation counter
by 1. Otherwise, the min_send_generation MUST remain unchanged. Prior
to sending a record, if min_send_generation is greater than the
current sending generation, the sender MUST first send a KeyUpdate."

This still leaves open the question of whether we should advertise the
receiving generation or have two ladders, but I believe those are
orthogonal to
David's issue. Does anyone see a reason why this won't work?


[0] My reasoning here is that it allows implementations who learn about new
limits for a cipher or are otherwise more conservative than their peer to
get more aggressive updates even if it's the other side doing most of the

On Thu, Aug 25, 2016 at 12:31 PM, Keith Winstein <>

> On Wed, Aug 24, 2016 at 9:23 PM, Ilari Liusvaara
> <> wrote:
> > The generations are not specified as integers. It is just some abstract
> > sequence (nowhere in protocol is that generations are integers used).
> The current draft requires that upon receipt of a KeyUpdate, "the
> receiver MUST update their receiving keys and if they have not already
> updated their sending state up to or past the then current receiving
> generation MUST send their own KeyUpdate prior to sending any other
> messages."
> This requires the generation counts to be comparable for inequality.
> Implementations will have to keep track of the generations, or the
> difference between them, in an integer counter. (How else would you do
> it?)
> > Due to design, one can't do a reciproal rekey.
> Hmm, there must be some misunderstanding. In the current draft,
> *every* time a node receives KeyUpdate #N (rekeying the incoming
> direction), it MUST reciprocate by rekeying its outgoing direction
> unless it has already sent at least N KeyUpdates. Current text: "This
> mechanism allows either side to force an update to the entire
> connection."
> >> (3) Fire-and-later-check. The TLS implementation exposes #2 above, but
> >> also `tls_session_generations()`, which returns a pair of integers
> >> giving the current sending and receiving generations.
> >>
> >> Any application we might want to build can be built on top of #3.
> >
> > Nope, the KeyUpdate is designed to deal with arbitrary latency in
> > order to fully decouple the direction (any coupling there would lead
> > to API problems, which apparently are more major than I initially
> > thought).
> Not quite sure what you're disagreeing with. Our proposal is also
> designed to deal with arbitrary latency. It's a field piggybacking on
> the otherwise-unmodified KeyUpdate messages.
> -Keith
> _______________________________________________
> TLS mailing list