Andrei Popov wrote: >Can you provide some references? I may have missed it: the only European >hybrid/composite requirements I saw were from BSI.
Thanks Stavros! In addition to the already talked about documents, there is also a formal document from ANSSI in French [1]. Companies in France tend to want compliance with ANSSI documents [1-2]. If they are requirements or just recommendations are not important, customers in Europe are not likely to accept solutions going completely against the recommendation of European security agencies. Recommendations from BSI/ANSSI also have an impact outside of EU. I have seen companies outside of the EU referring to BSI/ANSSI and saying they want solutions that are recommended by Five Eyes and EU. Cheers, John [1] https://cyber.gouv.fr/sites/default/files/2021/03/anssi-guide-mecanismes_crypto-2.04.pdf [2] https://cyber.gouv.fr/en/actualites/uses-and-limits-quantum-key-distribution From: Kousidis <kousidis.i...@gmail.com> Date: Monday, 28 July 2025 at 19:57 To: John Mattsson <john.matts...@ericsson.com>, tls@ietf.org <tls@ietf.org> Subject: Re: [TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3 You don't often get email from kousidis.i...@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> In order to have the primary literature cited, I think the most recent documents that recommend hybrids across borders in Europe (and I believe John already mentions) are A) To be viewed in security certifications of IT products within the EU Cybersecurity Certification Scheme on Common Criteria (EUCC): ECCG Agreed Cryptographic Mechanisms - version 2 (May 2025) https://certification.enisa.europa.eu/publications/eucc-guidelines-cryptography_en See e.g. "Note 51-Hybridization" that states "These cryptographic mechanisms are based on novel asymmetric primitives. To provide assurance against regression of robustness, they shouldn’t be used in a standalone way to provide the intended security functionality, but should be combined with a classicaly secure cryptographic mechanism." B) Broader Scope: A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography (June 2025) https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography See e.g. page 3 that contains "When migrating to post-quantum cryptographic solutions, it is recommended to use standardised and tested hybrid solutions, whenever feasible and suitable." @John: Thank you for your feedback on "SLH-DSA level 1", it might be that so far SLH-DSA is envisioned to be used in scenarios where even level 5 is feasible and/or required. Best, Stavros On 7/28/25 18:57, John Mattsson wrote: Peter C wrote: >because the motivating example seems to be DTLS Mobile systems use TLS/TCP, DTLS/UDP, DTLS/SCTP, and QUIC on both standardized and vendor-specific interfaces. All of them need to start migrating to PQC authentication urgently. Peter C wrote: >I think there are still open questions about amplification attacks The motivating use cases is local networks, where aplification attacks are not as big of a worry, and where the owner of the network can configure use of Large flight #1 or HRR. Bas Westerban wrote: >Sidestepping hybrid standardisation is an advantage, but I'm not yet ready to >admit failure there. For telecom, my view is that hybrid signatures are not mature and will not be mature in time to reach 100% PQC signatures in deployments 2030-2035. David Adrian wrote: >no one has put forward a grounded-in-reality use case for anything other than >SLH-DSA roots of trust. I don't know why you say that. Both Nokia and Ericsson is saying that SLH-DSA would be very practical for our use cases. David Adrian wrote: >Finally, in the event this is to be adopted, I should hope that we are able to >reduce the number of variants down to one or two, not 12. I would be fine to only standardize the SHAKE variants. ML-DSA and ML-KEM already relies 100% on Keccak. The SHAKE variant are much simpler, and (I think) easier to make side-channel resistant. 's' is needed for PKI and 'f' for CertificateVerify. I don't know if all security levels are needed. While I trust SLH-DSA level 1 more than RSA and ECC, some goverment agencies are for unknown and questionable reasons recommending level 3 and above, which is a _major_ problem for deployment. I really really hope all recommendations are updated to include SLH-DSA level 1. David Adrian wrote: >As far as I am aware, there is not a single normative requirement for a hybrid >signature in Europe. Even the BSI document [1] that most people cite as >support of hybrids is both clearly non-normative (recommendations only), >suggesting people _start planning_ and focused primarily on defending against >store-now-decrypt-later, where hybrids are already widely deployed. My understanding is that the European common criteria requirements do not allow pure ML-DSA. The recently released European timelines are also focused on firmware/software signing, which makes a lot of sense and aligns with CNSA 2.0. For TLS signatures the requirements/recommendations are 100% in deployments by 2030-2035. While 2035 is some time away, 10 years is not much time to completely change PKI roots-of-trust. In fact, it is urgent to start yesterday. With many security agencies in Europe strongly recommendin g against pure ML-DSA, there are many users in Europe that do not think pure ML-DSA is acceptable. Something that is not often discussed is that ANSSI (who I think is most important player in Europe) has said in the past (e.g. at PKIC) that pure ML-DSA will likely be allowed in the future. It would be very good with more clarity from European agencies... David Adrian wrote: >It also notes that many plans are use-case specific, e.g. just because we have >a hybrid kex in TLS, doesn't mean that a pure PQC signature wouldn't also make >sense. Agree, I would like to use X25519MLKEM768 with pure ML-DSA/pure SLH-DSA. Cheers, John
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
