On Fri, Aug 19, 2016 at 11:05 AM, Adam Langley <a...@imperialviolet.org> 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
