Re: [TLS] KeyUpdate and unbounded write obligations

[Keith Winstein <[e-mail]>]

On Fri, Aug 19, 2016 at 11:05 AM, Adam Langley <[e-mail]> 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
for.

-Keith