Re: [TLS] Comments on draft-ietf-tls-external-psk-importer-04

[Christopher Wood <[e-mail]>]

We chatted offline and updated the draft to refine some points:

   https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/36

Thanks for helping improving the document!

Best,
Chris

On Mon, Apr 27, 2020, at 7:08 AM, Hollenbeck, Scott wrote:
> > -----Original Message-----
> > From: Christopher Wood <[e-mail]>
> > Sent: Friday, April 24, 2020 7:09 PM
> > To: Hollenbeck, Scott <[e-mail]>; [e-mail]
> > Subject: [EXTERNAL] Re: [TLS] Comments on draft-ietf-tls-external-psk-
> > importer-04
> 
> [snip]
> 
> > > > Hmm, not quite. The statement intends to say that if you need EPSK k
> > > > into an importer and into TLS 1.2 then the resulting keys used in
> > > > TLS 1.3 and 1.2 are different. I'm not sure further clarification is
> > > > needed, though I'm happy to review suggestions if you have them!
> > >
> > > Agree with that as the goal.  Here's our concern in brief.  If our
> > > understanding is correct, prior to this draft, the client could use an
> > > EPSK k in two ways:
> > >
> > > * as input to the TLS 1.2 PRF (based on any hash function)
> > > * as input to the TLS 1.3 key schedule via HKDF-extract (based on a
> > > single hash function)
> > >
> > > Following this draft, the client could use k in two ways:
> > >
> > > * as input to the TLS 1.2 PRF (based on any hash function) [same as
> > > before]
> > > * as input to the importer function via HKDF-extract (based on a
> > > single hash function)
> > >
> > > So there is still a potential cryptographic overlap in the use of k
> > > between TLS 1.2 and TLS 1.3.  The imported keys don't have this
> > > overlap, because they're separated from one another and from the
> > > underlying EPSK through the use of the importer function.  But doesn't
> > > the security proof for k still need to take into account that the
> > > input to HKDF-extract might also be input to the TLS 1.2 PRF (with the
> > > same or a different hash function)?
> > >
> > > In other words, if it was a problem for the security proof that k
> > > could be input to the PRF and to HKDF-extract before the draft, isn't
> > > it still a problem afterwards?  The conclusion that there are no
> > > cross-protocol collisions depends on the specifics of the TLS 1.2 PRF
> > > and how it's used, compared to HKDF-extract.
> > >
> > > We're not suggesting there is any attack here, just trying to
> > > understand the design actually addresses the statement in the
> > > introduction that k "could possibly be re-used in two different
> > > contexts with the same hash functions during key derivation".
> > 
> > For lack of a better way to describe this (sorry!), we're trying to avoid this
> > input collision during the key derivation process of a TLS connection. As the
> > importer happens before a connection, and can be viewed as part of the
> > provisioning process that produces unique PSKs for each target hash
> > function, we achieve the goal for TLS 1.3 of not re-using a PSK with different
> > hash functions.
> > 
> > I'm not sure how to better clarify that right now, so suggestions are very
> > much welcome.
> 
> We're okay with the arguments in the draft that the design preserves 
> security proofs when the same EPSK is used to produce internal PSKs 
> associated with different hash functions within TLS 1.3 only. However, 
> it isn't clear enough to us how the design preserves security proofs 
> when the same EPSK is used with both TLS 1.2 and TLS 1.3.  I don't yet 
> have any text to suggest, because we're not sure we understand the 
> rationale. What is the rationale for the design in that situation?
> 
> Scott
>