Hi all, Be noted that in this discussion, I don't speak on behalf of anybody else including the NIST PQC team and my message does not intent to imply any technical policies in the future. I just wanted to explain some technical matters.
In SP 800-56C, we specified Z = Z' || T as an option where Z' is generated by a NIST-approved Key establishment scheme (either a key agreement such as DH or a key transport like RSA). My impression is that some people here are not happy about this. For the 1 step KDFs either with a hash function or a HMAC, the message input to the KDFs is always counter||Z||FixedInfo and FixedInfo is optional, and it can be a public value. So, Z = Z'||T keeps the status quo (not changing the analysis of the use of the one-step KDFs because one can treat T, not a NIST-approved shared secret value as a constant, a part of FixedInfo. In fact, for the one-step KDFs, replacing Z by Z'||T is exactly the same as changing FixedInfo to FixedInfo' = T||FixedInfo, an option that was already available to all implementations of the one-step KDFs in 56C. Why did we not allow Z to be T||Z' also in 56C ? We did not see any security reasons for doing it the other way around while we assumed that Z' is generated by a secure method and T is generated by a broken one. So, we did not see a need for a new variant. We also had a technical reason to not want people to have (ML-KEM-512 || RSA-3072 ) and (RSA-3072 || ML-KEM-512) (combos like that) to co-exist. Let's say we have 2 protocols: they do reverse order of each other: Z=Z1 || T1 and Z' = T2||Z2. 3 parties A, B and M. A and M do key exchange. B and M do key exchange and M is the bad guy, the attacker. M needs to send data to A and B to establish Z1, Z2, T1 and T2. For example, M uses ML-KEM to generate Z1 and Z2 then takes Z2 and Z1 to be T1 and T2 for M's key exchanges with A and B respectively by doing RSA key transports (Z2 and Z1 are the shared secrets of the 2 RSA key transports). So, in this case Z =Z1||T1 = Z1 || Z2 and Z' =T2||Z2= Z1 ||Z2, Z =Z'. Because of the existence of ML-KEM, A and B might expect that their shared secret keys with M from the hybrids are "random" and "unique". So, allowing both orders breaks that property. If T1 and T2 are (EC)DH, the attack wonโt work. If T1 and T2 are pre shared keys, then the attack is more complicated because M must generate Z1 and Z2 as ML-KEM shared secret keys with A and B, then make A and B agree to Z2 and Z1 as their pre-shared secrets T1 and T2 respectively before doing actual key exchanges with them. So, in theory this also works. If T1 and T2 are generated by another KEM, then the attack is possible depending on how T1 and T2 are generated by this KEM. For example, if this KEM does this: : (๐พ,๐) โ G(message), then the attacker M takes (๐โH(ek) in ML-KEM as โmessageโ ( (๐พ,๐) โ G(๐โH(ek)) is in ML-KEM). So, after generating Z1 and Z2 from ML-KEM, the attacker can generate T1 and T2 to be Z2 and Z1 respectively from this KEM. In this case, the attack works. This bad KEM works as a key transport because the Encaps side wholly decides the value of the shared secret keys T1 and T2. A counter argument to the importance of the attack above is that when M decides to do bad things, M wonโt do that because there are many worse things M can do. We understand that the attack above does not work for TLS 1.3 because the inputs to the Derive-Secret functions contain unique byte strings such as "c ap traffic" and the transcript. When we have a decision on this matter, our team will share it with you. Regards, Quynh. From: David Benjamin <david...@chromium.org> Sent: Wednesday, October 23, 2024 11:52 AM To: Joseph Birr-Pixton <jpix...@gmail.com> Cc: Salz, Rich <rsalz=40akamai....@dmarc.ietf.org>; John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org>; tls@ietf.org Subject: [TLS] Re: X25519MLKEM768 in draft-kwiatkowski-tls-ecdhe-mlkem-02 Oh I definitely agree there is a deeper problem here. It seems like NIST wrote something over-restrictive and then folks did a preemptive compliance maneuver to try to satisfy it. This is not a good way to do protocol development and hampers what should ultimately have been the goal for everyone: making TLS a good protocol to secure network communications. But, regrettable as it is, the damage has been done for X25519MLKEM768 and we shouldn't change it now. Fixing the underlying problem is for the future. The compliance schemes should be fixed so that they reflect the actual security needs here, and there is no reason to have an opinion on whether any particular compliance scheme's preferred secrets go first or second. After all, the entire point of this hybrid thing is that you don't have to care about the other input. On Wed, Oct 23, 2024 at 11:39โฏAM Joseph Birr-Pixton <jpix...@gmail.com<mailto:jpix...@gmail.com>> wrote: On Fri, 18 Oct 2024 at 15:12, Salz, Rich <rsalz=40akamai....@dmarc.ietf.org<mailto:40akamai....@dmarc.ietf.org>> wrote: To me, this trumps geek esthetics about making things line up. To be clear, my objection is not aesthetic or even about implementation effort. My concern is about rubber-stamping whatever unprincipled things that NIST comes up with. I also agree that altering X25519MLKEM768 (with the now-reversed order compared to X25519Kyber768) would be silly at this point -- and I think that goes probably for the name too. Thanks, Joe _______________________________________________ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
