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

[Benjamin Kaduk <[e-mail]>]

On Thu, Jul 26, 2018 at 10:58:05AM -0700, Eric Rescorla wrote:
> Ben,
> 
> Thanks for focusing on this issue.

Just trying to make sure loose ends get wrapped up before TLS 1.3 goes final...

> Chris and I have been discussing an alternative design which we think
> is more consistent with the existing structure, which we call PSK
> Importers. As with your design, we have an input universal PSK, but

(I think you mean David Benjamin's design?)

> instead of using explicitly as part of the connection, we just use it
> as the base key to import a set of new PSKs into TLS.
> 
> As with Universal PSKs (UPSKs), each input key is a triplet of
> (BaseIdentity, BaseKey, KDF), where a BaseIdentity is a PSK identity
> as used today. To use a UPSK, an implementation takes the set of KDF
> hashes it knows about H_i and derives a set of PSKs:
> 
>   Hash_i: H_i
>   Identity_i: BaseIdentity || H_i
>   Key_i: Derived from BaseKey and Identity_i
> 
> This gives you a set of keys which you can offer simultaneously on the
> TLS connection in independent psk_identity blocks. (Note that the hash
> algorithm is what differentiates each derived key.) This is a bit
> ugly, but with the current TLS 1.3 ciphers, this basically just means
> SHA-256, but even in the worst case it’s probably only 2-3.
> 
> The nice thing about this design is that if you know the set of hash
> functions, you can just compute all the imported PSKs in advance, and
> there’s no need to touch the internals of the TLS stack. This also
> means that if you have decided you don’t like old hash X, you don’t
> need to use it to compute PSK binders, you just use it do the KDF,
> which seems like it has weakersecurity requirements.
> 
> Here’s a specific construction, but we’re flexible about the details:
> 
>    struct {
>        opaque base_identity<1...2^16-1>;
>        HashAlgorithm hash;
>    } imported_psk_identity;
> 
>    UPSKx = HKDF-Extract(0, UPSK)  // UPSK is the input universal PSK
>    PSK = HKDF-Expand-Label(UPSKx, "derived psk", BaseKDF(psk_identity),
> TargetHash.length) // Might need to shorten label
> 
> These functions would be executed with the KDF associated with the UPSK,
> but produce
> a key the size of the desired hash.
> 
> This brings us to the question of TLS 1.2. I found Ilari’s analyis
> pretty persuasive, so I would suggest we add the following text to the
> TLS 1.3 spec:
> 
>     TLS 1.3 takes a conservative approach to PSKs by binding them to a
>     specific KDF. TLS 1.2 allows PSKs to be used with any hash function

(I know it's awkward to write about, but we don't really get away with
pretending that 1.2 1.3 are the only versions in the rest of the document.)

>     and the TLS 1.2 PRF. The constructions in TLS 1.2 and TLS 1.3,
>     although both based on HMAC, are very different and there is no known
>     way in which reuse of the same PSK in TLS 1.3 and TLS 1.2 would
>     produce related output, although only limited formal analysis has been
>     done. Implementations MAY wish to avoid reuse of keys between TLS 1.3
>     and TLS 1.2, or use a key derivation proposal such as [Informative ref
>     to this email or a draft].

I might add "to avoid the risk of using under-analyzed cryptographic constructions"
(or similar), but implicit might be good enough.

> 
> Other than this, we wouldn’t make any changes to the document.
> 
> What do people think?

This seems like a good sort of approach to take (that is, make the key derivation
for hash specificity something that happens outside of the TLS mechanics itself),
given the context in which we're thinking about it.

It might be worth going even farther, and including the target TLS version in the
(derived) identities and keys.  Though maybe the negotiation process means that
doesn't actually protect against an attack; I haven't thought it through enough.

Thanks for putting this together,

Ben (no hats)