On Thu, Jul 26, 2018 at 11:38 AM, Benjamin Kaduk <bka...@akamai.com> 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)
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
