[saag] Re: [EXTERNAL] post quantum guidance draft

Stephen Farrell <[email protected]> Sun, 7 Dec 2025 12:14:36 +0000
Newsgroups gmane.ietf.saag
Message-ID <[email protected]>
Hiya,

On 06/12/2025 18:22, John Mattsson wrote:
> Stephen Farrell wrote:
>> I think we won't know what guidance to offer for signatures for a
>> year or two more, or maybe even longer. Do nothing for now on
>> signatures
> 
> 
> I think standalone and hybrid signatures should be discussed
> separately. For hybrid signatures, I mostly agree with the points
> made above. For standalone signatures, I do not. 

We disagree so:-) I don't think we know what sig algs are
best for which uses nor when to use which in e.g. PKIs. And
we have some protocols like DNSSEC, where the current PQ
sig-algs just aren't a good fit. So, no, I do not think we
know what advice to offer for standalone PQ sigs. I do agree
things are even worse for hybrid sigs;-)

> In particular, for
> long-lived trust anchors, hardware devices, and digital contracts,
> areas where IETF standards are often used, a recommendation to
> “wait” would be dangerous.

I've seem that argument made a number of times. I'm unconvinced
TBH. But in any case, the draft says that there may be some niche
cases where the advice provided doesn't apply. IMO we ought not
let those niche cases drive so much of what's being done as we're
likely to inherit unnecessary complexity if we do.

(I also think security for many of those niche cases would be
better served by doing better on s/w or f/w update, but that's
another thing.)

Cheers,
S.

PS: Some text like that below might be something to provide as
advice in a few years, when we know more and there's more
consensus on the subject. I think it premature at this point.


> TLS WG has adopted ML-DSA and stated that
> dual certs/comp sigs will be "much later", which I think is the
> correct approach. For other use cases SLH-DSA, LMS, and XMSS might
> be suitable. https://datatracker.ietf.org/meeting/123/materials/
> slides-123-tls-wg-status-00
> 
> 
> Standalone: ------------------- Theoretically, I strongly prefer ML-
> DSA over RSA. I agree with Sophie’s statement that “my trust in
> lattice cryptography is pretty much equal to my trust in elliptic
> curves, and quite a bit higher than my trust in RSA,”. I think
> everyone should read her blog: https://keymaterial.net/author/
> sophieschmieg/
> 
> 
> From an implementation standpoint, I don’t expect ML-DSA
> implementations to be worse than many existing RSA or ECDSA
> implementations. In practice, many RSA and ECDSA implementations
> fail to follow any modern standard. ML-DSA may actually improve the
> situation by providing a single, well-defined specification (FIPS
> 204), whereas RSA and ECDSA suffer from an excess of specifications.
> 
> 
> Hybrids: ------------------- Hybrid signatures, like hybrid KEMs,
> should preserve the security properties of their components. For
> future deployments of PQ/T hybrids, this means maintaining the
> security of the PQ algorithm, since RSA and ECC should not be
> considered to provide any meaningful security beyond 2035.
> 
> 
> For ML-DSA hybrids, it is therefore essential that the construction
> preserves the SUF-CMA security of ML-DSA. EUF-CMA signatures often
> lead to availability and replay vulnerabilities at the system level.
> The critical importance of SUF-CMA has been highlighted by recent
> IETF discussions, in which several participants mistakenly argued
> that their use cases required only EUF-CMA security.
> 
> 
> Much of the discussion on hybrids over the past decade is now
> outdated, as it focused on preserving the properties of RSASSA-PKCS1-
> v1_5 and ECDSA during the transition to PQC. These discussions
> largely overlooked the fact that all modern signature schemes (LMS,
> XMSS, EdDSA, ML-DSA, SLH-DSA, and FN-DSA) are believed to offer a a
> high level of SUF-CMA security, while RSA and ECC have trivial SUF-
> CMA attacks. I believe separability has been given
> disproportionately more attention compared to other important
> properties.
> 
> 
> In general, the IETF should recommend against deploying PQ/T hybrids
> that do not preserve the security properties of the PQ signature. If
> such hybrids are nevertheless deployed, it is essential that they be
> disabled by 2035. As an alternative to changing algorithms, the
> simple hybrid signature mechanism described in Annex B.3.1 of ETSI
> TR 103 966, using independent fields rather than concatenation, can
> be used, with the traditional component disabled/removed by 2035. 
> https://www.etsi.org/deliver/
> etsi_tr/103900_103999/103966/01.01.01_60/tr_103966v010101p.pdf
> 
> 
> In general, I consider the following three types of PQ/T hybrids
> acceptable for new deployments with a lifetime beyond 2035: -
> Hybrids that preserve the security properties of both components. -
> Hybrids that preserve the security property of the PQ component. -
> Hybrids where the traditional part can be removed during a
> transition to a standalone PQ signature.
> 
> 
> In addition to offering no meaningful security beyond 2035, RSA
> signing is also significantly slower than ML-DSA for short messages. 
> https://blog.cloudflare.com/pq-2025/#the-zoo-of-post-quantum-
> signatures
> 
> 
> Cheers, John Prueß Mattsson
> 
>

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]
OpenPGP_signature.asc (application/pgp-signature, 236 B)
-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQQwbnhHy1kPJkWsM6fk2On5l6gz3QUCaTVvrQUDAAAAAAAKCRDk2On5l6gz3bhm
AQCgssSnvPEZxFjtjkwWap66p0iZhh/L5vA7QARr1XhstgD/Z9SF+oqPwyZTiRxGtlHmUgcIzLwj
uBrQS9IZRd9hoQ0=
=nh+I
-----END PGP SIGNATURE-----