Re: [TLS] Dumb thoughts for hardware backed keys for AEAD

[Bill Cox <[e-mail]>]

On Mon, Nov 30, 2015 at 7:53 PM, Eric Rescorla <[e-mail]> wrote:

> Ah, I see what you mean. Thanks for explaining.
>
> So, if I understand correctly, your threat model is that you want to
> prevent an attacker who obtains the traffic keys from injecting
> new traffic during the plausible lifetime of the connection
> (once close_notify has been exchanged, the traffic keys are
> useless).
>

Yes.


> Whether this is possible or not with a given AEAD transform seems
> to depend on the transform.
>

Agreed.


> FWIW, in the specific case of HMAC,
> because the key \xor pad fills an entire digest block, you might imagine
> storing the state of the outer compression function after the first block
> in the hardware module. I am not aware of any analysis that shows
> that this is safe and it very likely is not as strong as having the
> entire HMAC key in the module, but it might (or might not) be better
> than nothing.
>

I think it would not be hard to prove for HMAC/HKDF that this scheme has
similar defensive properties compared to the usual flow, with reasonable
assumptions about key generation.

However, the extra complexity in every TLS 1.3 implementation bothers me.
I worry that separating the read/write keys may not be worth it.  Did we
gain enough security to warrant the complexity?

Bill