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

[Nikos Mavrogiannopoulos <[e-mail]>]

On Thu, 2018-07-26 at 10:58 -0700, Eric Rescorla wrote:
> Ben, 
> 
> Thanks for focusing on this issue.
> 
> 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
> 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;

That looks nice, as it allows compatibility with existing psk
implementations.

One improvement could be to have a magic number, to allow easy
disambiguation between an potential existing "raw" (non ascii username
identity), and the new approach.

   struct {
       opaque magic[4]; // 0x544c0103
       HashAlgorithm hash;
       opaque base_identity<1...2^16-1>;
    } imported_psk_identity;

Such a field will also allow further future improvements to that
approach if needed and allow for incompatible changes in draft versions
as the magic serves as version number.

regards,
Nikos