Re: [TLS] KeyUpdate and unbounded write obligations

Ilari Liusvaara <> Sun, 28 August 2016 18:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F229A12B032 for <>; Sun, 28 Aug 2016 11:41:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I34VWCe_fud2 for <>; Sun, 28 Aug 2016 11:41:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F41D0127078 for <>; Sun, 28 Aug 2016 11:41:18 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8C5BFF4C; Sun, 28 Aug 2016 21:41:16 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id Xo0ujq-lkaLw; Sun, 28 Aug 2016 21:41:16 +0300 (EEST)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 7C9FE2313; Sun, 28 Aug 2016 21:41:16 +0300 (EEST)
Date: Sun, 28 Aug 2016 21:41:06 +0300
From: Ilari Liusvaara <>
To: Eric Rescorla <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.2-neo (2016-08-21)
Archived-At: <>
Cc: "" <>
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 18:41:21 -0000

On Sun, Aug 28, 2016 at 10:53:14AM -0700, Eric Rescorla wrote:
> 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.
> Specifically.
> "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."

Timing- and propagation-wise, it looks workable (also, could be done
with two flags[1], no need for counter).

Yes, this causes lots more desync between sides, but existing
mechanism needed to cope with that already.

However, one problem: Because both sides take their keys from one
ladder, if one side is behind the other, one can extract past keys
of other side from the one that is behind (running separate ladders
in both directions[2][3] would fix this).

[1] Specifically:
- last_tx_key_update: Was the last record I sent a KeyUpdate?
- next_tx_key_update: Will the next record I send be a KeyUpdate?

[2] Any current implementation likely already has per-direction
traffic secrets (at least mine certainly does). 

[3] Allowing multiple steps at once would open things up for DoS