Re: [TLS] KeyUpdate and unbounded write obligations

Adam Langley <> Fri, 19 August 2016 18:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CAA4712D82D for <>; Fri, 19 Aug 2016 11:05:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 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, HTML_MESSAGE=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 f_F9ICKObjef for <>; Fri, 19 Aug 2016 11:05:36 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B660612D8C1 for <>; Fri, 19 Aug 2016 11:05:34 -0700 (PDT)
Received: by with SMTP id q128so43927550wma.1 for <>; Fri, 19 Aug 2016 11:05:34 -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=IQdpYRfy1F5VXiIwyGJxhUNL8u+5PgeBNRSzOCsTSTs=; b=bsRUQyILkUNBsgXs4EWZkpW0vJG7U1BZd3fSDsYXFZwoaLIfqtzMbo7gNSdRTd+OMv xXNebBclyRSUUIMQ9SiTxzi3aUduQ8ChXHRdGXEgoM99SuAnlBLyJilWRw187rON0XlE fpSYo+s+sYjSyo1sHsSRmXE6s1BfuCbSW3hupzNaKsbWEhylFDyfcijgYxrwvHe8j46a 9vuZqbLqwfGOmk3KGyK3S8QC5PWV9vb8RuGB2cedj+Mx3UOuyUvK/FVnqsquS0ex5wh3 yHHhaFopdNVc8dYg2yoMqk61XCBQ3rCes9i6ENPJ5lWbec4EeCXfBXP9CLgFoQJcSgxN 6+Zg==
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=IQdpYRfy1F5VXiIwyGJxhUNL8u+5PgeBNRSzOCsTSTs=; b=BV9/HZKHG0Q/G92yeLb1v+SL4QUckUtOctu2kL0jGT+s24x95KoiNvnTt57JgZ0XWm d5EbccVwrKMJA0sO+QA0+eaiLcaDKZtlOpcMWhWkzH9wEnFI19DbvD3TwDZaX0DmHPLx eUFR2d7iinKZABKiwJxs3WDefgFYzur6D56Gl/CNLgmeH+mwZ0fzO0tItxamSzzu78nt wjQ1Y5q8fsBZMijD5mtpnVHlMerH9AYCwpVYdCzqRA9Wozb8mXpei0mwnv4lT+g324gV Xf/eE0Bd4QZm1wAA4xQ2pK04QdZji8HIfbvGgr6An29K9zqupPmES5xLTfOdxlKPLZ/h 3J+A==
X-Gm-Message-State: AEkoouvqGGGR4z5cMz96Nx2IjeMpn86/6XA4UJ6xe7fOwDstia/HZkzeeOuanNJsDVBXSiePZp3da2RWLW7lHw==
X-Received: by with SMTP id c199mr5221631wme.102.1471629933018; Fri, 19 Aug 2016 11:05:33 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 19 Aug 2016 11:05:32 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Adam Langley <>
Date: Fri, 19 Aug 2016 11:05:32 -0700
X-Google-Sender-Auth: YZzfQZ023-BDICYxkFJ3FDUCeBg
Message-ID: <>
To: Keith Winstein <>
Content-Type: multipart/alternative; boundary="001a114b2d306608af053a708b72"
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: Fri, 19 Aug 2016 18:05:39 -0000

On Thu, Aug 18, 2016 at 5:18 PM, Keith Winstein <>

> Yeah, our reasoning follows yours and goes a little further:
> 4) I don't know when I'm going to wake up again.
> 5) I don't want a subsequent compromise of me *or* the other side to
> reveal prior plaintext from the session.
> 6) Because I'm going to sleep, it's now or never to make sure the
> session keys aren't retained.
> 7) Therefore, I'd like to make sure both sides have ratcheted forwards
> before I go to sleep.

I don't think that a device can ensure that the other side doesn't get
compromised. Even if it rotates keys, there are plenty of ways that a well
meaning implementation could fail to erase them: copying GCs, swap,
hibernation, coldboots, even hypervisor tricks like moving VMs between

And I don't think the device can ensure that the keys that it writes to
flash aren't used to protect sensitive data without application-level
support. Consider a device that does a KeyUpdate and gets a KeyUpdate in
reply before sleeping. However, just after echoing the KeyUpdate, the other
side says "oh, and by the way, here are the battle plans...". Those plans
would be encrypted with keys that the device just wrote to flash. So there
has to be an application-level concept of "we're rotating keys now because
I'm going to sleep. These keys are only for authenticating another
KeyUpdate when I wake, don't send me anything." Once you have an
application-level concept like that then you don't need an special
KeyUpdate ack system at the TLS level because the KeyUpdate messages are
sequenced with the application data already.

Probably nothing that elaborate.
> The device is concerned that after the session is over (from its
> perspective), the server might get compromised, and the attacker reads
> the key for a long-dormant session out of the server's /dev/mem, and
> uses it to decrypt prior ciphertext.
> One approach is that the device should make sure to close every
> session with a secure bidirectional close, where the server actually
> confirms that the session is dead in both directions. But TLS does not
> have a secure bidirectional close. (Even when used, close_notify only
> promises there will be no more data in *that* direction.)
> However, the device can try to guarantee that both sides have
> ratcheted past all the keys that could reveal prior plaintext.

So you're worried that the server might not notice that a device has closed
a connection and so keep the keys in memory? Why didn't it notice? Because
an attacker cut the communication? If so, couldn't the attacker cut
communication just before the KeyUpdate and achieve the same thing?

Or are you assuming that we can't trust an implementation to erase keys
when a connection closes, but it will erase them for a KeyUpdate or a
bidirectional close? If so, I don't see why that's clearly true. It could
be true in practice, but I suspect that many implementations will do the
same thing in both cases. (And that, even if they try, they might not be
able to securely erase the keys because of swapping etc.)

The confirmation is the way for the device to know that the server has
> read its request to ratchet the client-to-server traffic key forwards.
> (And the idea would be, if the device doesn't get that confirmation
> and really wants it, it may have to raise a warning and handle this at
> the application layer -- e.g. by opening a new session to the server
> and issuing a "kill all sessions" command.)

That suggests that you're worried about an active attacker cutting
communications. But why would such an attacker let you open a new session?

> If they have a channel to the user where they are sending a stream of old
> > keys, couldn't they just mirror the plaintext of the connection to keep
> > things simple? I guess you worry about a device that's cooperative
> enough to
> > put in the effort to have their audit channel but lies about the
> plaintext?
> Right, exactly. (Ideally, the device doesn't even know it's being
> audited until the user logs in to the Web UI and says, "okay, now,
> ratchet the session and then share the old keys with this auditor that
> I am going to introduce you to, so it can decrypt some earlier
> ciphertext I've been capturing." So we don't want a parallel channel
> and we don't even want the device to have to know about the audit
> beforehand.)

I think that this is the most interesting case. I would like to think that
IoTish devices would care this much about doing the right thing, although I
suspect we're more likely to get more fodder for Matthew Garrett (

I would still tend towards not including the generation because I don't
believe that it's going to be used. But if, in a blaze of optimism, people
think it will, I'm not going to be too upset.



Adam Langley