Re: [TLS] KeyUpdate and unbounded write obligations

[Adam Langley <[e-mail]>]

On Thu, Aug 18, 2016 at 5:18 PM, Keith Winstein <[e-mail]>
wrote:

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

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 (
https://mjg59.dreamwidth.org/43486.html).

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.


Cheers

AGL

-- 
Adam Langley [e-mail] https://www.imperialviolet.org