[TLS] Re: FW: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt
On Mon, Mar 10, 2025 at 10:54:16AM +, Peter C wrote: > In ML-KEM, Bob derives b deterministically from m and H(ek). > If Bob tried to reuse b with a different public key, then the > re-encryption check would fail during decapsulation. Thanks for filling in my "momentary" lapse. Indeed the server is not free to choose a fixed "b" (ŷ). So server-side reuse is not possible as originally claimed. -- Viktor. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: FW: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt
Dang, Quynh wrote: >My guess is that that would be an expensive operation because of many reasons. Yes, and to make sure that the first two keys were not just before and just after a rekeying, you would need to look at three keys… While any timing side channels in X25519MLKEM768 are hopefully mitigated by the hybrid construction, this is not true with standalone ML-KEM. For standalone ML-KEM, it is even more important to forbid reuse of encapsulation keys when communicating with several peers. Also, standalone ML-KEM is even faster than the already very fast X25519MLKEM768, so there is even less justification for any reuse. Cheers, John From: Dang, Quynh H. (Fed) Date: Monday, 10 March 2025 at 14:09 To: tls@ietf.org Subject: [TLS] Re: FW: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt The server can detect a reused encapsulation key if it saves the keys which have been received and check the newly received key against the list of its saved keys. The server could just save the hashes of the keys or a "small" portion of the keys as the key IDs. My guess is that that would be an expensive operation because of many reasons. Regards, Quynh. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] RFC 8773bis status
draft-ietf-tls-8773bis has been in the “Held By WG” state since the Update to Standards Track / Working Group Last Call ended on 01 January 2024, see [0]. On 23 August 2024, we issued a consensus call to determine whether to require formal analysis in the symbolic model; see [1]. Between then and now, we tweaked the process somewhat to introduce a FATT point person and better described the process; see [2]. As a result, we: 1) Identified a FATT point person; Britta Hale generously offered to act as the point person for this draft - many thanks. 2) Received a FATT review report for draft-ietf-tls-8773bis; see [3] and please note the usage restrictions - many thanks again to the FATT members who participated in the review and to Britta for pulling it together. >From that report, we would like to note the following: Reviewer comments highlighted that the [-8773bis] technical changes to TLS through use of PSK are unlikely to introduce vulnerabilities to TLS in its current form, which should allay concerns from developers who rely on TLS security as-is and may have reservations about issues introduced by [-8773bis]. However, there were concerns about the claims of security offered under a quantum attacker and the [-8773bis] technical changes not aligning. To resolve the FATT comments, two courses of action were presented, namely reducing/revising security claims or seeking an analysis. Russ, the author, made adjustments to some of the security claims in the draft (see [4]) specially addressing some reviewer concerns about authenticity claims from the PSK. Some FATT open notes still remain, specifically that the draft claims continued TLS security against HNDL attacks. However, since the draft allows PSK reuse as well as group use, under a quantum attacker the draft does not provide “TLS security” but some form of group-like static key protection without the FS guarantees TLS now provides nor uniqueness of session keys. While this is not an issue with group PSKs under traditional attackers for the reason that the rest of the TLS handshake ensures unique client-server channel keys, it is an issue under a quantum attacker, which is the scenario that this draft claims TLS security against. The FATT recommendation was to select one of the following courses of action: a) restrict such PSK from reuse and group use to better match the intended TLS security, b) reduce or remove security claims on the TLS security provided under a quantum attacker, or c) seek analysis that will breakdown the exact security model that the draft provides and ensure the security considerations section matches that model. We will have time to discuss this at the IETF 122 meeting in Bangkok and will run a consensus call on the way forward soon after. Cheers, Sean, Deirdre, and Joe [0] Link to Update to Standards Track/Working Group Last Call completion message: https://mailarchive.ietf.org/arch/msg/tls/YLDjIzpwNB17dYlxmCPv-G3IdSk/ [1] Link to Consensus Call for Formal Analysis Requirement message: https://mailarchive.ietf.org/arch/msg/tls/M-ZBViaDQ0adftLrjZfZ-l7BMfI/ [2] Link to FATT process: https://github.com/tlswg/tls-fatt [3] Link to FATT report: https://github.com/tlswg/rfc8773bis/blob/main/fatt-review/IETF%20FATT%20Report%20-%208773bis.pdf [4] Link to diffs: https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-8773bis-04&url2=draft-ietf-tls-8773bis-05&difftype=--hwdiff ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: FW: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt
The server can detect a reused encapsulation key if it saves the keys which have been received and check the newly received key against the list of its saved keys. The server could just save the hashes of the keys or a "small" portion of the keys as the key IDs. My guess is that that would be an expensive operation because of many reasons. Regards, Quynh. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Exporter compatibility pitfall between (D)TLS 1.2 and 1.3
Hi all, I recently spent some time debugging an interop issue between WebRTC + DTLS 1.3 in Chrome and WebRTC + DTLS 1.3 in Firefox. The cause of the issue was a minor but interesting incompatibility between (D)TLS 1.2 and (D)TLS 1.3 that doesn't seem to have been flagged in RFC 8446 anywhere. Nothing actionable for this group, apart from maybe a last minute sentence to add to 8446bis (way too late to change how exporters work), but I thought I would pass it along for general awareness. WebRTC uses DTLS-SRTP, which uses export keying material to generate some specified number of bytes of data: https://www.rfc-editor.org/rfc/rfc5764.html#section-4.2 It turns out Firefox exported the maximum key+salt length and then only used a prefix of the output, rather than exporting the length as specified in RFC 5764. Back in 1.2, this was just fine and gave the right output. The requested length didn't figure into the derivation. But 1.3 incorporates the requested length into the derivation, so now this computes the wrong value. This means, starting with 1.3, applications must be sure to pass in exactly the length specified by the protocol they're implementing. Applications that relied on this 1.2 property will silently do the wrong thing when upgrading to 1.3. David ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Exporter compatibility pitfall between (D)TLS 1.2 and 1.3
Hi David, I remember that the same problem was discussed when standardizing EAP-TLS 1.3. The following text is in RFC 9190: “Note that the key derivation MUST use the length values given above. While in TLS 1.2 and earlier it was possible to truncate the output by requesting less data from the TLS-Exporter function, this practice is not possible with TLS 1.3. If an implementation intends to use only a part of the output of the TLS-Exporter function, then it MUST ask for the full output and then only use the desired part. Failure to do so will result in incorrect values being calculated for the above keying material.” I agree that it would be good if 8446bis discussed the problem. Cheers, John From: David Benjamin Date: Monday, 10 March 2025 at 21:20 To: Subject: [TLS] Exporter compatibility pitfall between (D)TLS 1.2 and 1.3 Hi all, I recently spent some time debugging an interop issue between WebRTC + DTLS 1.3 in Chrome and WebRTC + DTLS 1.3 in Firefox. The cause of the issue was a minor but interesting incompatibility between (D)TLS 1.2 and (D)TLS 1.3 that doesn't seem to have been flagged in RFC 8446 anywhere. Nothing actionable for this group, apart from maybe a last minute sentence to add to 8446bis (way too late to change how exporters work), but I thought I would pass it along for general awareness. WebRTC uses DTLS-SRTP, which uses export keying material to generate some specified number of bytes of data: https://www.rfc-editor.org/rfc/rfc5764.html#section-4.2 It turns out Firefox exported the maximum key+salt length and then only used a prefix of the output, rather than exporting the length as specified in RFC 5764. Back in 1.2, this was just fine and gave the right output. The requested length didn't figure into the derivation. But 1.3 incorporates the requested length into the derivation, so now this computes the wrong value. This means, starting with 1.3, applications must be sure to pass in exactly the length specified by the protocol they're implementing. Applications that relied on this 1.2 property will silently do the wrong thing when upgrading to 1.3. David ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: FW: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt
In ML-KEM, Bob derives b deterministically from m and H(ek). If Bob tried to reuse b with a different public key, then the re-encryption check would fail during decapsulation. Peter > -Original Message- > From: Viktor Dukhovni > Sent: 10 March 2025 00:47 > To: tls@ietf.org > Subject: [TLS] Re: FW: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt > > On Sun, Mar 09, 2025 at 11:17:10PM -, D. J. Bernstein wrote: > > > Viktor Dukhovni writes: > > > However, you'll be thrilled to learn that it is not possible for a TLS > > > server to reuse its ML-KEM keyshare when a client uses a fresh ephemeral > > > ML-KEM keyshare. > > > > "Not possible"? > > > > In ECDH, or more precisely ElGamal encrypton: Alice sends A = aG; Bob > > sends B = bG and C = bA+M; Alice recovers M as C-aB. > > > > In Kyber, Alice sends G and A = aG+e; Bob sends B = Gb+d and C = Ab+M+c; > > Alice recovers M by rounding C-aB. > > > > Bob can save time by reusing b. The speedup isn't as big as in the ECDH > > context if Alice chooses fresh G and A, but there's still _some_ > > savings, notably the time to prepare b for multiplication. > > > > I'm not saying that this is safe. I'm saying that it's what will happen > > if Bob is looking for the best speed that interoperates. It can also > > happen by accident, of course. > > I'd expect such designs to be quite unlikely, because in constrast with > static DH keys, there is no notion of "ŷ" as a static ML-KEM key. Also, > the APIs are not structured to support ŷ as an input to either > ML-KEM.Encaps(ek), or the derandomised ML-KEM.Encaps_internal(ek, 𝑚). > > One might also hypothetically use a constant "𝑚", compromising the > derived shared key: (𝐾, 𝑟) ← G(𝑚 ‖ H(ek)). > > I think the concern here is what "plasibly mainstream" implementations > are likely to do, where some reuse of client ephemeral keys can be > expected, but reuse of ŷ does not look particularly plausible. > > -- > Viktor. > > ___ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
