Re: [TLS] confirming the room’s consensus: adopt HKDF PRF for TLS 1.3

[Peter Gutmann <[e-mail]>]

Michael StJohns <[e-mail]> writes:

>This isn't about TLS specifically, but about how an HSM makes sure an
>attacker can't extract TLS keys.

Stepping back a bit in order to actually see the woods here, why is this an
issue?  Anyone who's using hardware for performance reasons will offload
everything to an SSL terminator, almost everyone else who doesn't want to do
that will do the crypto on the host, those worried about private-key security
will store the server key in an HSM but not do the bulk crypto there because
doing it on the host is typically much faster, and even if you do use PKCS #11
to do your bulk crypto for TLS, any attacker who's in a position to extract
the session keys from an HSM via a PKCS #11 mechanism has to control the host
it's talking to, in which case they've got direct access to the plaintext
anyway.

I realise that it's always possible to invent some scenario in which this is
an issue, but how much of a real-world impact does it actually have?  Bob
Relyea suggested TLS 1.2 PRF mechanisms in 2007 on the old Cryptoki list (and
it seemed his motivation for that was the need to be able to support it in
Mozilla's softoken implementation, for which he needed a defined PKCS #11
mechanism), and OASIS is just getting around to finalising the standard for
them now, seven years later.  This would seem to indicate that the actual
industry demand for this (not the hypothesised need but the real-world demand)
is a giant who-cares.

So as I've already said earlier in this discussion, create the best mechanism
that's a combination of good crypto design principles and ease of
implementation/deployment for existing implementations, and if someone
specifically wants to do it in an HSM they'll have to accept that they're the
odd corner case and deal with it.

Peter.