Re: [TLS] KeyUpdate and unbounded write obligations

Keith Winstein <> Thu, 25 August 2016 19:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 755AE12D0A0 for <>; Thu, 25 Aug 2016 12:32:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 BviXg-I0v9qd for <>; Thu, 25 Aug 2016 12:32:35 -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 1682212B024 for <>; Thu, 25 Aug 2016 12:32:35 -0700 (PDT)
Received: by with SMTP id u134so35830060ywg.3 for <>; Thu, 25 Aug 2016 12:32:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=eVHLi996WQLQq2p7myxKzbbth4wGWt0FRRAqqorZNKo=; b=pqkaSmQfadZJhjB6Bvqdj/mEBj2NrV2NifVPpTogiRrbnBtAsa7tW+Lp/wBB350r5k Wc/+Hi6Tu/PgwhWm+T+pdTNrppVZM1z/K7XT18eIzV4S5AB34OCNqYIA2EIPlIRIr3XC Isqrj3S6VunwXN3dkoYRsxCUCs1EdMkB4uL7+G6SOwEJ+Ep31hq7SgHi4HL2hg++lDjr FN0jwLqitjnGoi3slah6YYySUAlsAO1ELgWAWsNi6BWJL2yrLOGpMhLl7Vnm29wg4Iaf xASHwElnqtP2J6nQUdRh8sLZ6TAJq5afX6YjBO6wPRGVorTTb1uUFeqKIc6IpobFNiy6 Wrtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=eVHLi996WQLQq2p7myxKzbbth4wGWt0FRRAqqorZNKo=; b=fDs4JvNFXIgz0y5ldXs181zposOPh09c4HRki9pD3FSLgkmjA6bEjjTELqjF+hlB26 yQ0Y1pce0K79vrV+6h9NuCX+v2ybNdoUCjYtiIdYuCwaXXD8uMqIR1Gac3tpv10qJUPy nwrUjlc9FusEj7hyZ6Ob4q50tRLJ1QWWiEEBT++skno+BngWrkHkUxk7IWGskFSr2Cqe XmF0j9R3Y8tkmhb1at+Z3ABuY7tV42Yf27PCJ+McPtM+JbEFwwP85etXL3PCLk+g8zb3 zrX1E/XV4abKVjwrCGSWG14WvfxEvzvZo4SSKZHOFl7PcDHPc7vVVzuXgIBPdRwFD/m9 aEqw==
X-Gm-Message-State: AE9vXwNqjpqOVh3+jDFlss0+glTy2vmRCUYKSCj/By+BzEhnOAPDy2fpvGUkug6Wr62y8K/3EH7EKPVh8RCQMA==
X-Received: by with SMTP id a184mr9344892ywc.63.1472153554271; Thu, 25 Aug 2016 12:32:34 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 25 Aug 2016 12:31:53 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Keith Winstein <>
Date: Thu, 25 Aug 2016 12:31:53 -0700
X-Google-Sender-Auth: 46klo0JGB27DbEsAsPCeKpnL0xg
Message-ID: <>
To: Ilari Liusvaara <>
Content-Type: text/plain; charset="UTF-8"
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: Thu, 25 Aug 2016 19:32:36 -0000

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

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

> 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

>> (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.