Re: [TLS] KeyUpdate and unbounded write obligations

Subodh Iyengar <> Tue, 23 August 2016 18:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4994112D752 for <>; Tue, 23 Aug 2016 11:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jHKhmmaErqO0 for <>; Tue, 23 Aug 2016 11:47:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC8DE12D74F for <>; Tue, 23 Aug 2016 11:47:46 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id u7NIiNLt018897; Tue, 23 Aug 2016 11:47:34 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=facebook; bh=lVDcpmYSylpeXD5yLSIcYQ0FACZSeIfoOiw6Uf+t4z8=; b=avvRDwD/NYeoK053V1ShP8jHtWSl6Lp3PEEd6AEmIyzk0AYbC7fSiV7fIfXDKMallGKL DGnDWn81E1EKZ/f432JTn5y+nBT8xv/58pxQEyH2Lwxg3BuZEbqz67ggN5OiKsQiLkEC wvjbl1lSdSntLot3nFpsjvHsXotuTiel6tA=
Received: from ([]) by with ESMTP id 250sc9sy09-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Aug 2016 11:47:34 -0700
Received: from ([]) by ([fe80::5de8:34:5a87:6990%12]) with mapi id 14.03.0294.000; Tue, 23 Aug 2016 11:47:33 -0700
From: Subodh Iyengar <>
To: Keith Winstein <>, Stephen Farrell <>
Thread-Topic: [TLS] KeyUpdate and unbounded write obligations
Date: Tue, 23 Aug 2016 18:47:32 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-23_10:, , signatures=0
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: Tue, 23 Aug 2016 18:47:48 -0000

For people that currently use keyupdates or who are planning to use key updates, which layer are you planning to trigger a key update? Would the TLS implementation itself trigger the update or would the application trigger it? For renegotation, I believe it was mostly triggered by the application. 

For the use cases you mentioned Keith, they seem to be specific to application triggered key updates, i.e. key updates do not mean anything to the TLS layer apart from I got a key update and I must change keys. The fact that other side has thrown away it's key is only meaningful to the higher layer protocol. I imagine protocols like HTTP would not add these semantics, and these semantics would be added to very specific IoT protocols? Would the scope of the auditor be defined as a part of that protocol, or does it need to be defined as a part of TLS?

If key update is an application triggered mechanism, does the generation identifier need to be an integer to be understood by the TLS layer or could it also be an opaque identifier sent by the application. It would be much simpler not to have to deal with the requirements of consistency at the TLS layer and would make the API simpler.

From: TLS [] on behalf of Keith Winstein []
Sent: Friday, August 19, 2016 8:40 PM
To: Stephen Farrell
Cc: Adam Langley;
Subject: Re: [TLS] KeyUpdate and unbounded write obligations

On Fri, Aug 19, 2016 at 2:29 PM, Stephen Farrell
<> wrote:
> And for me, the dodgiest, by far. The scope for an "auditor"
> (what is that?) actually being an attacker is IMO way too
> high to consider standardising that kind of feature and any
> idea that it'd involve informed consent of someone seems to
> me fictional.

I appreciate the sensitivity of this issue to the WG. My read of your
email is that there's a concern that by standardizing a protocol
mechanism that allows a node to learn when its own KeyUpdate has
happened, the WG would imply approval of features that permit
the bad kind of eavesdropping. Here's why I don't think that's the case:

Our PR is for a piggyback integer field to provide security property
P3: "An implementation can learn that its request to rekey its
outgoing traffic has been read by the other side."

KeyUpdate is an *instruction* to the other side: "please update my key
in a forward-secure manner." We think some implementations will want
to know that the instruction has been carried out. And there's an easy
opportunity to do that here as a piggyback, without any extra protocol

A node will naturally care more about forward secrecy, and
confirmation of a forward-secure ratcheting event, the more it has
reason to suspect the keys might later be exposed to a third party. In
Berlin, I described three escalating cases: the (1) node going to
sleep, (2) node closing a connection without a mechanism for secure
bidi close, and (3) node that itself intends to release keys to a
read-only auditor after a ratchet is complete.

By "read-only auditor," we mean a curious person or security
researcher who owns an IoT device and wants to know what the heck it
is sending out of their house, where the device doesn't want to allow
its owner to add trusted certificates for an MITM. (This describes
most such devices today.)

Obviously I think it's valuable to make this mechanism available for
IoT device manufacturers. Having talked to several manufacturers, I'm
cautiously optimistic that some would use this. But the WG doesn't
have to take a position on this. These use cases are up to
implementers. There's nothing stopping an implementer today from
releasing session keys, or allowing complete MITM, as is the case in
the browser context with user- or admin-installed root CA
certificates. The TLS WG hasn't opined on these either.

To restate: Property P3 allows a node to learn that its KeyUpdate
instruction has actually happened, which in our view is useful and a
strict benefit over the status quo. It's also orthogonal to the issue
of unbounded write obligations raised in this thread.


TLS mailing list