Thanks, John. My comments inline.
Guilin 发件人：John Mattsson <[email protected]<mailto:[email protected]>> 收件人：Wang Guilin <[email protected]<mailto:[email protected]>>;Simo Sorce <[email protected]<mailto:[email protected]>>;Lucas Prabel <[email protected]<mailto:[email protected]>>;Orie <[email protected]<mailto:[email protected]>> 抄 送：jose <[email protected]<mailto:[email protected]>>;jose-chairs <[email protected]<mailto:[email protected]>>;cose <[email protected]<mailto:[email protected]>>;Wang Guilin <[email protected]<mailto:[email protected]>> 时 间：2025-10-18 15:33:53 主 题：Re: [jose] Re: Call for Adoption request: draft-prabel-jose-pq-composite-sigs-04 I agree with many of the comments regarding the complexity of hybrid signatures. In practice, hybrid signatures are significantly more complex than hybrid KEMs. -------------- GL' comments: Great. Yes, hybrid signatures is much more complex than hybrid KEMs, as the latter normally do not use certificates. -------------- >Choice C: Hybrid (including dual or composite signatures etc), which is a >conservative and balanced approach, but also an improving one. If hybrid signatures are to be deployed today or in the future, I do notthink those specified in draft-ietf-lamps-pq-composite-sigs or draft-prabel-jose-pq-composite-sigs should be used. Theyare not improving ones, they are guaranteed to reduce the proven SUF-CMA security of ML-DSA to trivial attacks. -------------- GL' comments: For SUF-CMA security, it is nice as we are together working on a draft now (to be submitted by 20 Oct, I think). But personal opinion is still the same: It is very important and SHOULD highlight the difference between SUF-CMA and EUF-CMA security. But, just from now raising the bar to SUF-CMA security seems too hurry and aggressive. In paricular, neither NIST nor ISO lists SUF-CMA as the security requirement for PQ sinature algorithms for standardizing. The Chinese new NGCC does lists it, but as an optional property. However, working on such a draft should be good as some applications may need it now or soon. -------------- NIST’s statements in SP 800-227 regarding composite KEMs apply equally to composite signatures: “A well-constructed composite KEM C[Π1, Π2] should preserve the security properties of its component KEMs Π1 and Π2.” "Therefore, NIST encourages the use of key combiners that generically preserve IND-CCA security" -------------- GL' comments: Nice to know this. -------------- The properties you want from aPQ/T hybrid changes over time: - Pre-2024: PQC not standardized and should be seen as contributing zero security. Security relies on Traditional. Important that the hybrid does not weaken the security of Traditional. - 2024-2035: It's complicated - Post-2035: Traditional disallowed and should be seen as contributing zero security. Security relies on PQC. Important that the hybrid does not weaken the security of PQC. The composites in draft-ietf-lamps-pq-composite-sigs and draft-prabel-jose-pq-composite-sigs wereok before 2024. However, I don’t think anyone should deploy them today, and I believe they should be disallowed by 2035, alongside RSASSA-PKCS1-v1_5. -------------- GL' comments: Yes, as you mentioned "2039-2035: It's complicated". My previous explains why I think hybrid is particularky important for such uncertain periods. "The composites in draft-ietf-lamps-pq-composite-sigs and draft-prabel-jose-pq-composite-sigs were ok before 2024." "Before 2024"? I think you mean "before 2035". Right? "However, I don’t think anyone should deploy them today, " The message sent by John Gary today says that they have customers using/asking composite signatures. I also know several companies are considering to deploy their own PKIs with composite signatures or HBS schemes. -------------- Cheers, John (as an individual) From:Wang Guilin <[email protected]<mailto:[email protected]>> Date: Saturday, 18 October 2025 at 08:21 To: Simo Sorce <[email protected]<mailto:[email protected]>>, Lucas Prabel <[email protected]<mailto:[email protected]>>, Orie <[email protected]<mailto:[email protected]>>, John Mattsson <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, cose <[email protected]<mailto:[email protected]>>, Wang Guilin <[email protected]<mailto:[email protected]>> Subject: RE: [jose] Re: Call for Adoption request: draft-prabel-jose-pq-composite-sigs-04 Do not agree several points about the value of hybrid and its complexity. > And for short term protection there is no point in dual signatures, if a CRQC > is available the classic part is irrelevant. And until a CRQC is available > the QR part is redundant. The point is: Customers (and also professionals, like experts here) do not exactly know when CRQC will be available. So, there is a long period up to years for such uncertainty. For example, if this uncertain period is 2030-2035, what customers should do in 2030 or 2031? - Choice A: Just keep traditional cryptography for the services and systems, but do nothing on PQ migration. Then, they may lost their business soon due to either their competitors supporting PQ or losing their business in reality for CRQC appearance. - Choice B: Migrate to pure PQ solution from now. Yes, good. However, the majority of professionals (at least in IETF and cryptography community) do think that PQ algorithms are not yet as mature as traditional ones. So just bet on the security of one single PQ algorithm may be risky. I would like to assign a probability of 10^{-2} for such a risk, if a number is good for illustration, while a mature traditional algorithm may just have the risk probability like 10^{-3} or even 10^{-4}. - Choice C: Hybrid (including dual or composite signatures etc), which is a conservative and balanced approach, but also an improving one. (PQUIP has several good documents on this line). The simplest reason for this hybrid is that it can improve practical security level, i.e., reduce risk probability. For a right hybrid solution, once the above traditional algorithm and PQ algorithm are used via hybrid, the resulting services or systems will only have only risk probability as low as 10^{-5} or even 10^{-6}. Namely, risk only happens if both algorithms fails. This is actually a huge security improvement, compared with the risk probability of 10^{-2} for pure PQC solution, in this simulated setting. After a number years of time testing, such systems can update to pure PQ algorithm or even PQ+PQ hybrid solution when a CRQC arrives ore nearly arrives. In particular, businesses demanding high security will benefit from hybrid. (I would like to call this as a little new "theory" about PQ migration. I will be happy to explain more later.) The blog at https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.cr.yp.to%2F20251004-weakened.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0f2aff835a7146969b9b08de0e0e7fa5%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638963652603692944%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XtiHa18NEVSjb%2BJW0hbhFF12CD%2FFWRqChdOGlDhCXd4%3D&reserved=0<https://blog.cr.yp.to/20251004-weakened.html> gives much more reasons and cases with details, on a similar topic: "It's normal for post-quantum cryptography to be rolled out as an extra layer of security on top of traditional pre-quantum cryptography, rather than as a replacement." Yes, just like you, many may say Choice C (Hybrid) will increase migration complexity. > I think this will just add complexity with no value, complexity means more > bugs and more ways to screw up, and must always be justified. Yes, complexity or performance overhead will be introduced. But, it may be not that much. As I remember, both AWS and Cloudflare did some experiments a few years ago, which showed that network performance for employing PQ (or hybrid) normally drops something like 10%. By considering the continuous hardware updates, this is not a big issue. In real application, migration complexity is tightly related to soft engineering, it would be hard to analyze in a simple way. However, at the protocol level (the target of IETF), I do think it is not too much complex, compared with pure PQ solution. Three examples. 1) TLS takes concatenation way to do hybrid key exchange (KE), so this mainly means to add a new KE algorithm ID for a hybrid algorithm combination (say ECDH+ML-KEM). It do not introduce essential change for either the TLS protocol or implementation/crypto library. 2) IKEv2 does this differently as the first IKE_SA_INIT exchanges can not be fragmented. So, PQ KEMs will be run after ECDH has been run first. Though this introduces more interactions between two peers, IPSECME WG reached its consensus on this approach and published RFC 9370, in May 2023. 3) The last one, Composite ML-DSA for use in X.509 Public Key Infrastructure (draft-ietf-lamps-pq-composite-sigs-12). It is well known in IETF that this is a tough work for the author team and also for the group. However, IMO, here are the two main reasons: a) ML-DSA defined two private key formats and several variants for this "one" particular PQ signature algorithm. b) It is the first try for defining PKI with composite or hybrid signatures. For future ones, a lot of experience learned will be helpful and save our energy. > - If a CRQC is expected soon all this work is net overhead for basically no > gain as classic signatures will be obsolete quickly, and going though > composite signatures will cause dual migrations classic -> composite -> > pureQR, which is operationally expensive and doubles the pain. "If a CRQC is expected soon ... ": This just one case, with very small probability. So, more is about the case if a CRQC will come 10 or 15 years later. We and customers should concern much more for this case, as it is expected to happen with big (if not overwhelming) probability. As explained the above, "soon all this work is net overhead for basically no gain .." may not really true, as hybrid improves system security level, and also boosts the research and standardization of generic hybrid approaches, including PQ+PQ solutions. First of all, " dual migrations" and "composite" may be treated in the same category, as both are concrete ways of realizing hybrid. "will cause dual migrations classic -> composite -> pureQR, which is operationally expensive and doubles the pain." Not really, if my explanation the above sounds right. From now, it may be more practical to expect that all those approaches will be supported simultaneously in most applications. So, essentially one surgery for all pain. For those with strong confidence in a single PQ algorithm, no problem, just go ahead, if they have no concern on the issues like the difference between risk probability of 10^{-2} and 10^{-5}. > - If a CRQC is not expected soon, then rushing into composites is also not > useful, it is better to stay on a classic signature until the time pureQR are > trustworthy enough to do the migration once. The above explained already. The PQ migration has a long period of uncertainty. A lot of customers may like to brace the benefits of both traditional cryptography and PQ algorithms, especially in this long uncertain period. > Because I do not see a cryptographic relevant justification I am somewhat > against adding composite signatures to JOSE (can't speak about COSE because I > am not as familiar with its application space). Read the above blog and several documents in PQUIP should help, I think. On the other hand, this document does not give much justification why PQ or why hybrid approach, as it supposes that the background more or less like explained the above. Guilin -----Original Message----- From: Simo Sorce <[email protected]<mailto:[email protected]>> Sent: Saturday, 18 October 2025 3:42 am To: Lucas Prabel <[email protected]<mailto:[email protected]>>; Orie <[email protected]<mailto:[email protected]>>; John Mattsson <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; cose <[email protected]<mailto:[email protected]>> Subject: [jose] Re: Call for Adoption request: draft-prabel-jose-pq-composite-sigs-04 Lucas, while LAMPS may have different needs, I do not understand what composites bring to JOSE or COSE, the JWT and JWS tokens are generally short-lived entities, therefore there is no need for long term protection against CRQC. And for short term protection there is no point in dual signatures, if a CRQC is available the classic part is irrelevant. And until a CRQC is available the QR part is redundant. I think this will just add complexity with no value, complexity means more bugs and more ways to screw up, and must always be justified. Additionally, in terms of timing: - If a CRQC is expected soon all this work is net overhead for basically no gain as classic signatures will be obsolete quickly, and going though composite signatures will cause dual migrations classic -> composite -> pureQR, which is operationally expensive and doubles the pain. - If a CRQC is not expected soon, then rushing into composites is also not useful, it is better to stay on a classic signature until the time pureQR are trustworthy enough to do the migration once. Note that for a PKI infrastructure that provides CA certificates that have a long life the considerations may be quite different, so LAMPS has more reasons to entertain composite signatures at least for CA certificates. Because I do not see a cryptographic relevant justification I am somewhat against adding composite signatures to JOSE (can't speak about COSE because I am not as familiar with its application space). Simo. On Fri, 2025-10-17 at 15:35 +0000, Lucas Prabel wrote: > > > Hi Orie, thanks for your feedback. > > I think the point about the specific use cases is not specific to hybrid > composite signatures, but could also be raised for pure PQ signatures, which > didn’t prevent the COSE ML-DSA draft to be adopted by the COSE WG. > > The LAMPS composite draft has already been adopted and is in WGLC. Given the > 2030 migration timelines announced by several security agencies and > organizations, I also believe waiting too long to standardize such mechanisms > could make it difficult for some systems to achieve compliance in time. > > Best, > > Lucas > -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc _______________________________________________ jose mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
