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

[Eric Rescorla <[e-mail]>]

On Thu, Jul 26, 2018 at 11:38 AM, Benjamin Kaduk <[e-mail]> wrote:

> 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?)
>

Oh, yeah. I originally meant to be responding to davidben and then forgot
to edit
the msg.

>
> > 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.)
>

Fair enough.



> >     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.
>

I like that.

-Ekr


> >
> > 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)
>