Re: [TLS] KeyUpdate and unbounded write obligations

Keith Winstein <> Sat, 20 August 2016 03:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40ED412D597 for <>; Fri, 19 Aug 2016 20:35:55 -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 naEvh-HPfHKu for <>; Fri, 19 Aug 2016 20:35:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4C47812D593 for <>; Fri, 19 Aug 2016 20:35:52 -0700 (PDT)
Received: by with SMTP id u134so23749453ywg.3 for <>; Fri, 19 Aug 2016 20:35:52 -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=h+EeRQ9FVLJgtZaQpqTz4+PNYDvgjKbsFk6IVeVCpy0=; b=MzrY4WOyisgxleeAwz0n+Lrgy9SP8QxZrHFSsBdaGRj83t9gBi7LVw2INyweni+JmV nY4q+nVpDKChuyCJjhpJ99ziJhMPeGMYJ+k5Ph6O06DeUwswvvB1K5PH3qhAu0Gjs6rY NbfVvT0gDS2dwLoE0qAg0VJ52uJIy7Rz2vjoTwCbQ3+nvv7DtxoN7fSToa7MeNBsd6He CwURgoBTgsSeritJjkcei5rqzHEOOryjLdk+SGB4PUk8gDaLKvpijiBcqNJM5YheLpvD fgwr/O9o+iwJA+QbWU5BStm5+CgxXjYuDzStaxrJCggSLY5rwgs38emLPlsZhk25NJaa ABHg==
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=h+EeRQ9FVLJgtZaQpqTz4+PNYDvgjKbsFk6IVeVCpy0=; b=UAe9Xhj95qULscNn8U/O23qsXTtK/IzmnTWNjLct7p7BO0DTsLYndsooc63DMexK/X PeFaq6HNtUj8Qv2C0l+b+Q7Pbu04nHw31Vis9TtKWYiDQrt5nFYUvumQz0ahG719nlYB IjbmhfYbu9iTZClD3Bf9F0ALojD/CNf8ugB/PfXPJZ5NfXYaTMMOMoMztKsMLIlKICnI OgbpM6ragOFu5U1ZWHrhnNq3SY1b3ogawT80Uqc6P+AB/+6Z9hNaMePmMtLqDXjryCic F6UFDV4dLDI/tb+8V4U3aDRCisWxhi9jeAqBoEQIaL8S/3RzCNI/O/tE6JE1aWQL8gy9 k50A==
X-Gm-Message-State: AEkoous2xwImZ8kd8CYCY+GREODC2d/PF+gqrjo3qPWgHzbfwWEeMg/CCfvSr/iuEDgl+loAIUIqKeSdFOrYMQ==
X-Received: by with SMTP id m20mr9266597ywd.183.1471664151356; Fri, 19 Aug 2016 20:35:51 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 19 Aug 2016 20:35:10 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Keith Winstein <>
Date: Fri, 19 Aug 2016 20:35:10 -0700
X-Google-Sender-Auth: qQnbNSdM-uR1yh61VhDwU8ENDMg
Message-ID: <>
To: Adam Langley <>
Content-Type: text/plain; charset="UTF-8"
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: Sat, 20 Aug 2016 03:35:55 -0000

On Fri, Aug 19, 2016 at 11:05 AM, Adam Langley <> wrote:

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

Sure. This is true of every forward-secret mechanism -- I don't think
KeyUpdate is unique. As you probably know better than me, the hope of
PFS is that key deletion (of the keys that can decrypt the ciphertext)
happens in the window after the ciphertext is received and before the
keys are compromised. But obviously it's different to have a protocol
that supports PFS vs. actually deleting the keys.

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

Sure, you're right about new data that the server sends on its own
initiative after a ratchet. You do still protect all the data that was
sent in the prior epoch.

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

Obviously, in the real world the mechanism is much more useful if it
works with typical unmodified webservers and TLS terminators. If I
wanted to build my own application-layer protocol, I wouldn't be here.
(Mosh *has* a secure bidi close...)

> 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?

I send you a close_notify, and you send me a close_notify. Have you
stopped trusting input from my key? Have you deleted my key? There's
no way for me to tell. That's the worry. If I send you a KeyUpdate,
and you increment your receive_generation and tell me, then I know you
SHOULD have deleted the prior key. That's the most I can really ask