Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3

[Jonathan Hoyland <[e-mail]>]

Hi all,

Couldn't make it to the second TLS session, but I did suggest on the
mailing list a tweak to the universal PSK draft that achieves
compatibility, unambiguity, and is straight-forward to prove secure
formally. (By which I mean prove independent of the security of TLS 1.2,
and thus any hash function it uses, even a pathalogical one.)
https://www.ietf.org/mail-archive/web/tls/current/msg26419.html
In brief I suggest that you transform both the PSK ID and the PSK itself in
such a way that a server that accepts them tacitly acknowledges the upgrade
of the PSK from 1.2 to 1.3.
You can achieve compatibility with a server that doesn't support this by
offering the untransformed PSK ID also, at the cost of a more complex
formal analysis / potentially weaker security.

Regards,

Jonathan

On Fri, 20 Jul 2018 at 15:22 Ilari Liusvaara <[e-mail]>
wrote:

> On Fri, Jul 20, 2018 at 08:42:47AM -0400, David Benjamin wrote:
> >
> > (I suspect using the same key with TLS1.2-PRF-SHA256 and HKDF-SHA256 is
> > probably *more* risky than mixing HKDF-SHA256 and HKDF-SHA384. I don't
> > think we actually believe SHA256 and SHA384 give related output. It's
> just
> > nice to avoid the assumption. Whereas TLS1.2-PRF-SHA256 and HKDF-SHA256
> > actually a chance of misbehavior. Perhaps it's worth doing that
> analysis?)
>
> TLS 1.3 does this with PSK:
>
> HMAC(<zeroes>, PSK)
>
> And TLS 1.2 does:
>
> HMAC(<expanded PSK>, <some data>)
>
> (where <some data> actually depends on <expanded psk>). Now, it is
> possible that there is second similar block in there, but that uses
> the same <expanded PSK>.
>
>
> However, noteworthy point is that there is only two ways to end up in
> situation where the effective key in TLS 1.2 is all zeroes:
>
> 1) <expanded psk> is longer than hash block and is preimage of 0.
>    Finding such thing is supposed to be infeasible.
> 2) The PSK is empty. However, the <some data> on TLS 1.2 side is
>    not empty in this case (it starts with gunk from HMAC that
>    involves at least both randoms). Also, empty PSK is not secure.
>
>
> The definition of HMAC is:
>
> H(C(key) XOR opad | H(C(key) XOR ipad, data))
>
> Which preserves collision resistance on C(key) and data. Now, C(key)
> is not collision resistant. However, the only possible cases where
> C(key) can collide are the two above.
>
>
> So it seems to me that TLS 1.2 and TLS 1.3 compute independent
> things from PSK values, in all practical cases.
>
>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>