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 <c...@heapingbits.net> > > Sent: Friday, April 24, 2020 7:09 PM > > To: Hollenbeck, Scott <shollenb...@verisign.com>; TLS@ietf.org > > 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 > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
