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