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

[Michael StJohns <[e-mail]>]

On 4/27/2015 2:06 AM, Peter Gutmann wrote:
> 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.


All of these are fair points - but miss the point that only small 
changes to what we do in TLS will permit securing all of the key 
material in the HSM and will not add to the cost of a software 
implementation.  Whereas, if you don't do anything, (or you do things 
like generating IVs as secret material), then the only choice is for the 
HSM to implement a highly specific TLS crypto system and mark keys as 
only for use in TLS.  Even then, I can't see how to reconcile security 
between that and the need for exporters given the current definitions.

With respect to TLS1.2 PRF et al in PKCS11 - imputing the delay in 
adding TLS1.2 to the spec to a general lack of a desire to do this in 
hardware is probably at best only partially correct.  A more correct 
assignment of blame is probably due to the small uptake of TLS1.2 
deployments.  See 
https://jve.linuxwall.info/blog/index.php?post/TLS_Survey  - I'm not 
sure how valid the methodology is, but that's 33% in January 2014 and 
apparently a lot less in 2010 - see page 37 of 
http://blog.ivanristic.com/Qualys_SSL_Labs-State_of_SSL_2010-v1.6.pdf. I 
have this suspicion that Heartbleed is at least a substantial driver for 
the increase.

Currently (TLS1.2 and before), generic HSMs can protect the server key 
pair and, once inserted in the HSM, the session keys.  What they can't 
protect are the steps between.  That's an artifact of:  use of the same 
key for both MAC and key expansion and pseudorandom bit generation (e.g. 
Initial IV and Session Nonce generation); the lack of cryptographic 
binding between the length and type of the output keys and the key 
stream generation in the key expansion formation.

In any event, there's something of a chicken and egg problem. People 
don't implement TLS using hardware because the hardware doesn't exist.  
HSM vendors don't implement TLS (or only implement PKCS11's definition 
of TLS) because the user base isn't there.  Both wait for the other.  
That also applies between versions - finding a good implementation of 
TLS1.2 was dependent on there being a market for it and that market took 
a while to develop as TLS1.0 and 1.1 were working fine for the generic 
customer (until they weren't....).

Finally, someone somewhere has figured out that they don't need to break 
into a system and steal the plain text if they can just get the system 
to send it the keys as they generate them.    I have no idea if anyone 
has accomplished such attack successfully, but it's one that bothers me 
because of how hard it might be to detect and ultimately protect 
against.  The only real defense against such an attack is a security 
module hardened against over the air attacks - hardening the system only 
gets you so far.

I've pushed hard on this because if it isn't fixed in TLS1.3, it will be 
at least 10 years to the next deployment iteration.  It seems silly to 
do something that can't be secured if it's relatively easy to do 
something that can be secured.



Later, Mike