Hi Authors, *Paul, *Paul - As delegated AD for this document, please review and approve the following updates (which can be viewed in this diff file: https://auth48-transition.rfc-editor.org/authors/rfc10024-auth48diff.html). Once we receive your approval, we will move this document forward in the publication process.
- Added text to Section 6 (Security Considerations) - [NIST-SP-800-56A] reference moved from the Normative References section to the Informative References section Authors - We have noted all of your approvals here: https://queue.rfc-editor.org/final-review/rfc10024/. Kris, Douglas - Thank you for pointing out the issue! We have updated the document accordingly. The files have been posted here: https://www.rfc-editor.org/authors/rfc10024.txt https://www.rfc-editor.org/authors/rfc10024.pdf https://www.rfc-editor.org/authors/rfc10024.html https://www.rfc-editor.org/authors/rfc10024.xml Updated diffs: https://www.rfc-editor.org/authors/rfc10024-diff.html https://www.rfc-editor.org/authors/rfc10024-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc10024-auth48diff.html https://www.rfc-editor.org/authors/rfc10024-auth48rfcdiff.html (side by side) Thank you, Madison Church RFC Production Center > On Jul 30, 2026, at 6:08 AM, Kris Kwiatkowski <[email protected]> wrote: > > Hi, > > We just found > > Hi, > > Apologies for following up after my earlier approval - Douglas spotted one > more issue. > > In Section 2 > OLD: > Key establishment using NIST curves is outlined in Section 6.1.1.2 of > [NIST-SP-800-56A]. > > NEW: > Key establishment using NIST curves is outlined in Section 6.1.2.2 of > [NIST-SP-800-56A]. > > > My approval otherwise stands. > > Best, > Kris > > On 7/30/26 11:23, Kris Kwiatkowski wrote: >> Approved. >> Thank you all. >> On 7/30/26 03:16, Kampanakis, Panos wrote: >>> Approved, thank you. >>> >>> -----Original Message----- >>> From: Douglas Stebila <[email protected]> >>> Sent: Wednesday, July 29, 2026 7:38 PM >>> To: Madison Church <[email protected]> >>> Cc: Bas Westerbaan <[email protected]>; Kris Kwiatkowski >>> <[email protected]>; Kampanakis, Panos <[email protected]>; Paul Wouters >>> <[email protected]>; Bas Westerbaan >>> <[email protected]>; Joseph Salowey <[email protected]>; >>> RFC Editor <[email protected]>; [email protected]; >>> [email protected]; [email protected]; [email protected]; >>> [email protected] >>> Subject: RE: [EXTERNAL] [AD] Final Review: RFC-to-be 10024 >>> (draft-ietf-tls-ecdhe-mlkem) in XML >>> >>> CAUTION: This email originated from outside of the organization. Do not >>> click links or open attachments unless you can confirm the sender and know >>> the content is safe. >>> >>> >>> >>> I approve. >>> >>> Douglas >>> >>> >>> >>>> On Jul 29, 2026, at 4:54 PM, Madison Church <[email protected]> >>>> wrote: >>>> >>>> Hi Bas, >>>> >>>> Thanks for the quick reply! We've made the requested updates and noted >>>> your approval here: https://queue.rfc-editor.org/final-review/rfc10024/. >>>> >>>> Updated files (please refresh): >>>> https://www.rfc-editor.org/authors/rfc10024.txt >>>> https://www.rfc-editor.org/authors/rfc10024.pdf >>>> https://www.rfc-editor.org/authors/rfc10024.html >>>> https://www.rfc-editor.org/authors/rfc10024.xml >>>> >>>> Updated diffs: >>>> https://www.rfc-editor.org/authors/rfc10024-diff.html >>>> https://www.rfc-editor.org/authors/rfc10024-rfcdiff.html (side by side) >>>> https://www.rfc-editor.org/authors/rfc10024-auth48diff.html >>>> https://www.rfc-editor.org/authors/rfc10024-auth48rfcdiff.html (side >>>> by side) >>>> >>>> We will assume your assent to any further changes submitted by your >>>> coauthors unless we hear objection at that time. We will await approvals >>>> from each of the parties listed at the Final Review status page prior to >>>> moving this document forward in the publication process. >>>> >>>> Thank you! >>>> Madison Church >>>> RFC Production Center >>>> >>>> >>>>> On Jul 29, 2026, at 3:38 PM, Bas Westerbaan <[email protected]> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> On 29 Jul 2026, at 22:09, Madison Church <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Bas, Kris, *Paul, >>>>>> >>>>>> *Paul - As delegated AD for this document, please review and approve the >>>>>> following updates (which can be viewed in this diff file: >>>>>> https://auth48-transition.rfc-editor.org/authors/rfc10024-auth48diff.html). >>>>>> - Added text to Section 6 (Security Considerations) >>>>>> - [NIST-SP-800-56A] reference moved from the Normative References >>>>>> section to the Informative References section >>>>>> >>>>>> Bas, Kris - Thank you for your replies! We have updated the document >>>>>> accordingly and just have 2 followup items for your review. >>>>>> >>>>>> 1) We have updated [DUALECTLS] according to our new Reference Style >>>>>> Guidance available on authors.ietf.org <http://authors.ietf.org/> (see >>>>>> https://authors.ietf.org/en/reference-style-guidance#conference-papers) >>>>>> to include the conference name and the authors of this paper. >>>>>> >>>>>> Current: >>>>>> [DUALECTLS] >>>>>> Checkoway, S., Fredrikson, M., Niederhagen, R., >>>>>> Everspaugh, A., Green, M., Lange, T., Ristenpart, T., >>>>>> Bernstein, D., Maskiewicz, J., and H. Shacham, "On the >>>>>> Practical Exploitability of Dual EC in TLS >>>>>> Implementations", 23rd USENIX Security Symposium (USENIX >>>>>> Security 14), 2014, >>>>>> <https://www.usenix.org/system/files/conference/ >>>>>> usenixsecurity14/sec14-paper-checkoway.pdf>. >>>>>> >>>>> Looks good. If you allow multiple initials, then I’d use “Bernstein, D. >>>>> J.,” instead of “Bernstein, D.” here. >>>>> >>>>> >>>>> >>>>>> 2) We’ve updated the Security Considerations section per your replies. >>>>>> >>>>> I spotted a typo. >>>>> >>>>> OLD: >>>>> In contrast, the ECDHE ephemeral scalars taken from the RNG are never >>>>> >>>>> NEW: >>>>> In contrast, the ECDH ephemeral scalars taken from the RNG are never >>>>> >>>>> >>>>> >>>>>> Please review this section carefully to ensure we’ve captured everything >>>>>> correctly. In addition, we have slightly modified the last sentence to >>>>>> 1) use the correct form of "affect" (verb) vs. "effect" (noun), and 2) >>>>>> reduce the slight repetition of the phrase "as well" at the end of the >>>>>> last two sentences in this section. Let us know if there are any >>>>>> objections. >>>>>> >>>>>> Current: >>>>>> If the same insecure RNG is used by both algorithms, then a >>>>>> disclosure of state by one of the algorithms will also affect the >>>>>> security of the other algorithm. >>>>>> >>>>> Looks good. >>>>> >>>>> >>>>>> Authors - Please review the document carefully to ensure satisfaction as >>>>>> we do not make changes once it has been published as an RFC. Contact us >>>>>> with any further updates or with your approval of the document in its >>>>>> current form. We will await approvals from each author prior to moving >>>>>> forward in the publication process. >>>>>> >>>>> With the typo corrected, I approve. Thank you! >>>>> >>>>> Best, >>>>> >>>>> Bas >>>>> >>>>> >>>>>> The files have been posted here (please refresh): >>>>>> https://www.rfc-editor.org/authors/rfc10024.txt >>>>>> https://www.rfc-editor.org/authors/rfc10024.pdf >>>>>> https://www.rfc-editor.org/authors/rfc10024.html >>>>>> https://www.rfc-editor.org/authors/rfc10024.xml >>>>>> >>>>>> The relevant diff files have been posted here (please refresh): >>>>>> https://www.rfc-editor.org/authors/rfc10024-diff.html >>>>>> https://www.rfc-editor.org/authors/rfc10024-rfcdiff.html (side by >>>>>> side) https://www.rfc-editor.org/authors/rfc10024-auth48diff.html >>>>>> https://www.rfc-editor.org/authors/rfc10024-auth48rfcdiff.html (side >>>>>> by side) >>>>>> >>>>>> For the Final Review status page, please see: >>>>>> https://queue.rfc-editor.org/final-review/rfc10024/ >>>>>> >>>>>> Thank you! >>>>>> Madison Church >>>>>> RFC Production Center >>>>>> >>>>>> >>>>>> >>>>>>> On Jul 29, 2026, at 12:48 AM, Kris Kwiatkowski <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> (Sending again for improved readability) Dear Madison, Co-authors, >>>>>>> all >>>>>>> >>>>>>> After reading the text I've found few editorial defects >>>>>>> >>>>>>> In 8.1 >>>>>>> OLD: >>>>>>> >>>>>>> [NIST-SP-800-227] >>>>>>> Alagic, G., Barker, E., Chen, L., Moody, D., Robinson, A., >>>>>>> Silberg, H., and N. Waller, "Recommendations for Key- >>>>>>> Ecapsulation Mechanisms", National Institute of >>>>>>> Standards >>>>>>> >>>>>>> NEW: >>>>>>> >>>>>>> [NIST-SP-800-227] >>>>>>> Alagic, G., Barker, E., Chen, L., Moody, D., Robinson, A., >>>>>>> Silberg, H., and N. Waller, "Recommendations for Key- >>>>>>> Encapsulation Mechanisms", National Institute of >>>>>>> Standards >>>>>>> >>>>>>> (typo: there is missing 'n' in Encapsulation) >>>>>>> >>>>>>> In 4.2 >>>>>>> OLD: bytes for the ML-KEM part and 97 bytes for secp384r1) >>>>>>> NEW: bytes for the ML-KEM part and 97 bytes for secp384r1). >>>>>>> >>>>>>> (typo: final '.' is missing). >>>>>>> >>>>>>> In 4.3 >>>>>>> OLD: the concatenation of the ECDHE and ML-KEM shared secret >>>>>>> NEW: the concatenation of the ECDHE and ML-KEM shared secrets? >>>>>>> (typo: shouldn't secret be plural?) >>>>>>> >>>>>>> In 6. >>>>>>> Please add following text at the end of the section: >>>>>>> "If the same insecure RNG is used by both algorithms then a >>>>>>> disclosure of state by one of the algorithms will effect the security >>>>>>> of the other algorithm as well." >>>>>>> >>>>>>> It was committed here, at a later stage: >>>>>>> https://github.com/tlswg/tls-ecdhe-mlkem/pull/71 >>>>>>> >>>>>>> In 8.1 >>>>>>> I believe [NIST-SP-800-56A] should be moved from normative to >>>>>>> informative references. It is only cited in 2. and informatively. >>>>>>> >>>>>>> Otherwise, the document looks great (taking into account recent >>>>>>> feedback from Bas). >>>>>>> >>>>>>> Cheers, >>>>>>> Kris >>>>>>> >>>>>>> On 7/28/26 23:53, Joseph Salowey wrote: >>>>>>> >>>>>>>> You might need to use dark mode to see Kris' edits (for me, the >>>>>>>> text is white on a white background). Also for the text in 6 - "If >>>>>>>> the same insecure RNG is used by both algorithms then a disclosure >>>>>>>> of state by one of the algorithms will affect the security of the >>>>>>>> other algorithm as well." This text was submitted as an >>>>>>>> individual, without a chair hat on. Feel free to omit it if you >>>>>>>> think it's getting in the weeds. >>>>>>>> >>>>>>>> Joe >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jul 28, 2026 at 3:39 PM Kris Kwiatkowski <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Dear Madison, Co-authors, all >>>>>>>>> >>>>>>>>> After reading the text I've found few editorial defects >>>>>>>>> >>>>>>>>> In 8.1 >>>>>>>>> OLD: >>>>>>>>> >>>>>>>>> [NIST-SP-800-227] >>>>>>>>> Alagic, G., Barker, E., Chen, L., Moody, D., Robinson, A., >>>>>>>>> Silberg, H., and N. Waller, "Recommendations for Key- >>>>>>>>> Ecapsulation Mechanisms", National Institute of Standards >>>>>>>>> >>>>>>>>> NEW: >>>>>>>>> >>>>>>>>> [NIST-SP-800-227] >>>>>>>>> Alagic, G., Barker, E., Chen, L., Moody, D., Robinson, A., >>>>>>>>> Silberg, H., and N. Waller, "Recommendations for Key- >>>>>>>>> Encapsulation Mechanisms", National Institute of Standards >>>>>>>>> >>>>>>>>> (typo: there is missing 'n' in Encapsulation) >>>>>>>>> >>>>>>>>> In 4.2 >>>>>>>>> OLD: bytes for the ML-KEM part and 97 bytes for secp384r1) NEW: bytes >>>>>>>>> for the ML-KEM part and 97 bytes for secp384r1). >>>>>>>>> >>>>>>>>> (typo: final '.' is missing). >>>>>>>>> >>>>>>>>> In 4.3 >>>>>>>>> OLD: the concatenation of the ECDHE and ML-KEM shared secret >>>>>>>>> NEW: the concatenation of the ECDHE and ML-KEM shared secrets? >>>>>>>>> (typo: shouldn't secret be plural?) >>>>>>>>> >>>>>>>>> In 6. >>>>>>>>> Please add following text at the end of the section: >>>>>>>>> "If the same insecure RNG is used by both algorithms then a >>>>>>>>> disclosure of state by one of the algorithms will effect the security >>>>>>>>> of the other algorithm as well." >>>>>>>>> >>>>>>>>> It was committed here, at a later stage: >>>>>>>>> https://github.com/tlswg/tls-ecdhe-mlkem/pull/71 >>>>>>>>> >>>>>>>>> >>>>>>>>> In 8.1 >>>>>>>>> I believe [NIST-SP-800-56A] should be moved from normative to >>>>>>>>> informative references. It is only cited in 2. and informatively. >>>>>>>>> >>>>>>>>> Otherwise, the document looks great (taking into account recent >>>>>>>>> feedback from Bas). >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Kris >>>>>>>>> >>>>>>>>> On 7/28/26 19:01, Bas Westerbaan wrote: >>>>>>>>> >>>>>>>>> Hi Madison, >>>>>>>>> >>>>>>>>> Thanks for the quick edits. >>>>>>>>> >>>>>>>>> On 28 Jul 2026, at 19:19, Madison Church >>>>>>>>> <[email protected]> wrote: >>>>>>>>> >>>>>>>>> Hi Authors, >>>>>>>>> >>>>>>>>> Thank you for your responses! We have updated the document >>>>>>>>> accordingly and have 5 followup items for your review (we’ve tried to >>>>>>>>> consolidate updates per everyone’s responses here, but please let us >>>>>>>>> know if we’ve missed something). Updated files have been posted below >>>>>>>>> in this thread. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Edits looks good. But on reading I see now that we shouldn’t use >>>>>>>>> ECDHE instead of ECDH in one spot: the IANA Considerations (Section >>>>>>>>> 7). >>>>>>>>> >>>>>>>>> OLD: >>>>>>>>> Comment: Combining X25519 ECDHE with ML-KEM-768 >>>>>>>>> >>>>>>>>> NEW: >>>>>>>>> Comment: Combining X25519 ECDH with ML-KEM-768 >>>>>>>>> >>>>>>>>> >>>>>>>>> OLD: >>>>>>>>> Comment: Combining secp384r1 ECDHE with ML-KEM-1024 >>>>>>>>> >>>>>>>>> NEW: >>>>>>>>> Comment: Combining secp384r1 ECDH with ML-KEM-1024 >>>>>>>>> >>>>>>>>> >>>>>>>>> OLD: >>>>>>>>> Comment: Combining secp256r1 ECDHE with ML-KEM-768 >>>>>>>>> >>>>>>>>> NEW: >>>>>>>>> Comment: Combining secp256r1 ECDH with ML-KEM-768 >>>>>>>>> >>>>>>>>> >>>>>>>>> Also I spotted an old typo in Douglas’ e-mail address. >>>>>>>>> >>>>>>>>> OLD: >>>>>>>>> [email protected] >>>>>>>>> >>>>>>>>> NEW: >>>>>>>>> [email protected] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 1) For the following (from Deb): >>>>>>>>> >>>>>>>>> Please note that some of the text that was agreed during wglc for >>>>>>>>> draft-ietf-tls-mlkem need to be added to this draft as well >>>>>>>>> (specifically the randomizer text, when it applies to this draft). >>>>>>>>> >>>>>>>>> >>>>>>>>> Authors - Can you point us to the final text that should be added to >>>>>>>>> the document (and where the text should be placed)? We note that this >>>>>>>>> pull request (https://github.com/tlswg/tls-ecdhe-mlkem/pull/69) has >>>>>>>>> been merged, but we want to make sure we incorporate the correct text. >>>>>>>>> >>>>>>>>> >>>>>>>>> Section 6 (Security Considerations) >>>>>>>>> >>>>>>>>> OLD: >>>>>>>>> All groups defined in this document use and generate fixed-length >>>>>>>>> public keys, ciphertexts, and shared secrets, which complies with >>>>>>>>> the requirements described in Section 6 of [RFC9954]. >>>>>>>>> >>>>>>>>> NEW: >>>>>>>>> All groups defined in this document use and generate fixed-length >>>>>>>>> public keys, ciphertexts, and shared secrets, which complies with >>>>>>>>> the requirements described in Section 6 of [RFC9954]. >>>>>>>>> >>>>>>>>> During ML-KEM encapsulation, encapsulation randomness <tt>m</tt> >>>>>>>>> is drawn from a random bit generator and encrypted (see >>>>>>>>> [NIST-FIPS-203], Algorithms >>>>>>>>> 17 and 20); the client, which holds the decapsulation key, then >>>>>>>>> recovers <tt>m</tt> exactly during decapsulation (see >>>>>>>>> [NIST-FIPS-203], Algorithm 18). Consequently, any information >>>>>>>>> <tt>m</tt> carries about the generator's other outputs is also >>>>>>>>> exposed to the client. >>>>>>>>> >>>>>>>>> The disclosure of the output(s) of an insecure random number >>>>>>>>> generator (RNG) when used in TLS can be used in an attack to >>>>>>>>> compromise the state of the insecure RNG itself as described in >>>>>>>>> [DUALECTLS]. The encapsulation randomness <tt>m</tt> in ML-KEM is >>>>>>>>> an additional place where RNG output is disclosed to an active >>>>>>>>> attacker. >>>>>>>>> Implementers should follow the RBG guidance in [NIST-FIPS-203] >>>>>>>>> and the random number generation guidance in Appendix C.1 of >>>>>>>>> [RFC9846]. >>>>>>>>> Implementers can choose to implement mechanisms from [RFC8937] >>>>>>>>> for additional protection across sessions. >>>>>>>>> >>>>>>>>> In contrast, the ECDHE ephemeral scalars taken from the RNG are >>>>>>>>> never directly disclosed to the peer. However, any passive >>>>>>>>> observer with access to a cryptographically relevant quantum >>>>>>>>> computer (CRQC) can recover the scalar, which is derived directly >>>>>>>>> from RNG output. >>>>>>>>> Regardless, ephemeral scalars should always be generated using a >>>>>>>>> cryptographically secure RNG: for secp256r1 and secp384r1 as >>>>>>>>> required by [NIST-SP-800-56A], and for X25519 as described in >>>>>>>>> [RFC7748]; the guidance in Appendix C.1 of [RFC9846] applies here as >>>>>>>>> well. >>>>>>>>> >>>>>>>>> >>>>>>>>> Section 8.2 (Informative References) >>>>>>>>> >>>>>>>>> Please add the following two references (cited by the new Section >>>>>>>>> 6 text above): >>>>>>>>> >>>>>>>>> NEW: >>>>>>>>> >>>>>>>>> [RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., >>>>>>>>> and C. Wood, "Randomness Improvements for Security Protocols", >>>>>>>>> RFC 8937, DOI 10.17487/RFC8937, October 2020, >>>>>>>>> <https://www.rfc-editor.org/rfc/rfc8937>. >>>>>>>>> [DUALECTLS] >>>>>>>>> "On the Practical Exploitability of Dual EC in TLS >>>>>>>>> Implementations", 2014, >>>>>>>>> <https://www.usenix.org/system/files/conference/ >>>>>>>>> usenixsecurity14/sec14-paper-checkoway.pdf>. >>>>>>>>> >>>>>>>>> >>>>>>>>> Section 1 (Introduction) >>>>>>>>> >>>>>>>>> OLD: >>>>>>>>> ML-KEM is a key encapsulation mechanism (KEM) defined in the >>>>>>>>> [NIST-FIPS-203]. >>>>>>>>> >>>>>>>>> NEW: >>>>>>>>> ML-KEM is a key encapsulation mechanism (KEM) defined in >>>>>>>>> [NIST-FIPS-203]. >>>>>>>>> >>>>>>>>> Section 4.2 (Server Share) >>>>>>>>> >>>>>>>>> OLD: >>>>>>>>> The size of the server share is 1665 bytes (1568 bytes for the >>>>>>>>> ML-KEM part and 97 bytes for secp384r1) >>>>>>>>> >>>>>>>>> NEW: >>>>>>>>> The size of the server share is 1665 bytes (1568 bytes for the >>>>>>>>> ML-KEM part and 97 bytes for secp384r1). >>>>>>>>> >>>>>>>>> 2) We have updated with your proposed title with further improvements >>>>>>>>> per Panos’ suggestion regarding the use of "post-quantum hybrid" (see >>>>>>>>> #4 below). Please let us know any objections. >>>>>>>>> >>>>>>>>> Current (Title): >>>>>>>>> Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms >>>>>>>>> for TLS 1.3 >>>>>>>>> >>>>>>>>> Current (Abbreviated Title): >>>>>>>>> PQ/T Hybrids for TLS 1.3 >>>>>>>>> >>>>>>>>> >>>>>>>>> Looks good to me. >>>>>>>>> >>>>>>>>> >>>>>>>>> 3) For consistency throughout the document, we have updated each >>>>>>>>> instance of "Elliptic Curve Diffie-Hellman" and "ECDH" to "Ephemeral >>>>>>>>> Elliptic Curve Diffie-Hellman" and "ECDHE", respectively. Please >>>>>>>>> review and let us know any objections. Additionally, should the >>>>>>>>> keyword "ECDH" be updated to "ECDHE"? >>>>>>>>> >>>>>>>>> >>>>>>>>> Perhaps both like RFC 10015? >>>>>>>>> >>>>>>>>> >>>>>>>>> 4) Per Panos’ suggestion, we have updated to use "PQ/T" in the >>>>>>>>> document after the expansion "Post-Quantum Traditional" to align with >>>>>>>>> RFC 9794. Let us know if you prefer otherwise. >>>>>>>>> >>>>>>>>> >>>>>>>>> Looks good. >>>>>>>>> >>>>>>>>> 5) Would adding a citation for RFC 9794 after "Post-Quantum >>>>>>>>> Traditional (PQ/T) hybrid key agreements" work here? >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> This document introduces three new supported groups for >>>>>>>>> Post-Quantum Traditional (PQ/T) hybrid key agreements in TLS 1.3 >>>>>>>>> -- X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 -- >>>>>>>>> that combine ML-KEM with Ephemeral Elliptic Curve Diffie-Hellman >>>>>>>>> (ECDHE) in the manner described in [RFC9954]. >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> This document introduces three new supported groups for >>>>>>>>> Post-Quantum Traditional (PQ/T) hybrid key agreements [RFC9794] >>>>>>>>> in TLS 1.3 -- X25519MLKEM768, SecP256r1MLKEM768, and >>>>>>>>> SecP384r1MLKEM1024 -- that combine ML-KEM with Ephemeral Elliptic >>>>>>>>> Curve Diffie-Hellman (ECDHE) in the manner described in [RFC9954]. >>>>>>>>> >>>>>>>>> >>>>>>>>> Yes. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Bas >>>>>>>>> -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
