Re: [TLS] KeyUpdate and unbounded write obligations

[Keith Winstein <[e-mail]>]

On Thu, Aug 18, 2016 at 2:26 PM, Adam Langley <[e-mail]> wrote:

> I think I was because I hadn't seen your Berlin presentation. But I'm still
> going to hijack this thread and ask you to expand on some of these points so
> that I understand your motivation :)

Fair enough. :-)

>> - An embedded device may wish to fully rotate the session keys before
>> going to sleep.
>
> I imagine the argument here goes:
>
> 1) Sleep is good because it saves power.
> 2) To sleep we need to power down (and erase) most memory.
> 3) So to keep a TLS connection across sleep/wake secrets have to be saved to
> flash, but that's hard to erase so we don't want to expose keys that were
> used to encrypt traffic.

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.

> For that I see why one needs KeyUpdate to be echoed: as the embedded device,
> you want the peer to rotate keys so that you can write only fresh keys to
> flash. On wake you want the other side to rotate again so that the keys in
> flash were only used to authenticate a new KeyUpdate.
>
> But why do you need the other side to have confirmed that it has erased your
> keys? I think you only care that it echos your KeyUpdate messages promptly.

Agreed, P1+P2 is sufficient if the device only cares about making sure
*it* is not going to leak keying material (that can reveal prior
plaintext) if there is a compromise during sleep. You need P3 if you
are also concerned the peer might be holding on to an old key.

>> - A paranoid device might fully rotate the session keys before closing
>> the session. (If confirmation is absent, the device might use a
>> higher-level mechanism to forcibly log out all open sessions from that
>> user.)
>
> The worry here is that a peer might be seized and subject to a cold-boot
> attack to lift the TLS connection keys? So if you don't hear from it every
> $x seconds you'll log it out?

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.

> Again does the confirmation here help?

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

> What if you send a KeyUpdate and receive a change password request? The peer
> might well have sent it before receiving your KeyUpdate, or maybe it was seized and
> will just choose not to echo your KeyUpdate.

Sure, there's nothing you can do if the peer gets compromised while
important keys still live on it. But the idea here is for the device
to be able to make sure the keys get ratcheted after all the data is
sent but before there can be a later compromise. Basically
approximating (some of) the semantics of an actual secure
bidirectional close.

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

-Keith