[saag] Re: [Ext] Re: draft-paulwh-crypto-components-02

Paul Wouters writes:
"The recent past (eg non-pq) shows a narrowing of algorithms to mostly be 1 NIST and 1 non-NIST
algorithm"

I am very much against this description. My view is that the IETF choses algorithms on technical merits. While the CFRG standardization of elliptic curves was to a large degree driven by the Snowden revelation and a wish to have non-NSA curves, the reason Curve25519 is dominating deployments is that it has superior properties.

For hash functions the IETF uses two NIST algorithms, and for XOFs only NIST algorithms.

I find the suggestion from some people to use non-NIST algorithms rather strange. When NIST (hopefully) standardizes Classic McEliece, some heads will explode in confusion wheather it is a NIST or DJB algorithm….

John

From: D. J. Bernstein <[email protected]>
Date: Sunday, 16 February 2025 at 13:41
To: [email protected] <[email protected]>
Subject: [saag] Re: [Ext] Re: draft-paulwh-crypto-components-02
Paul Wouters writes:
  [ regarding the claim that "The recent past (eg non-pq) shows a
    narrowing of algorithms to mostly be 1 NIST and 1 non-NIST
    algorithm" ]
> I was referring to an apparent convergence for non-pq cryptography
> (inside and outside IETF) to support P256-AES-GCM and
> 25519-POLY-CHACHA.

You mean the _TLS WG_ decision of which options to label as MUST and
SHOULD in TLS 1.3?

Here's that WG's consensus declaration, which doesn't fit the claimed
pattern of mandating "P256-AES-GCM and 25519-POLY-CHACHA", doesn't
endorse a 1-NIST-1-non-NIST policy, and doesn't even say "NIST":

    https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FVnQZ0FGmAkzqE2x5hH-gO4nry9E%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C761537cbf2df453b870508dd4e873c30%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638753064916414576%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9tYhNmt85UrH9yBEaT9B2VBr746S4xpojRY%2FUu9JXls%3D&reserved=0<https://mailarchive.ietf.org/arch/msg/tls/VnQZ0FGmAkzqE2x5hH-gO4nry9E/>

Or do you mean what's actually _used in TLS_ today, which is mostly
RSA-2048 for certificates, mostly X25519 for key exchange, and mostly
AES-128-GCM for encryption? Some references:

    https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FpQRDJ9MBwnmLHp86Zvs_CfYUFaY%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C761537cbf2df453b870508dd4e873c30%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638753064916438795%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=s4ljke6x7G6tRpnh8Vz%2Fe6gnDw%2BNZp8gH%2BEFsW8HZQY%3D&reserved=0<https://mailarchive.ietf.org/arch/msg/tls/pQRDJ9MBwnmLHp86Zvs_CfYUFaY/>
    https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FlWh_uimMIgQ6SMV_BSkJDh34eQM%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C761537cbf2df453b870508dd4e873c30%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638753064916450530%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nvFwMhy7ZYgnCh0OAH2Cm8AKCCyWF9zBSSt5TpuUtTk%3D&reserved=0<https://mailarchive.ietf.org/arch/msg/tls/lWh_uimMIgQ6SMV_BSkJDh34eQM/>
    https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FvWAEg7E3jeLZjLABVaMVLR0flX4%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C761537cbf2df453b870508dd4e873c30%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638753064916461523%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VgCwXSoy0lHzDvCk0fEIxWw424OwlsQRuJbgggog2C4%3D&reserved=0<https://mailarchive.ietf.org/arch/msg/tls/vWAEg7E3jeLZjLABVaMVLR0flX4/>
    https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ssllabs.com%2Fssltest%2FviewClient.html%3Fname%3DChrome%26version%3D80%26platform%3DWin%252010%26key%3D170&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C761537cbf2df453b870508dd4e873c30%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638753064916472458%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=AKGx3AdW2VU7TBaGwR39zJ%2BIVBktbe4MCRkh%2BRNNJR0%3D&reserved=0<https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome&version=80&platform=Win%2010&key=170>

Looking beyond TLS (and "outside IETF"), many of the cryptographic
applications listed on the following pages weren't using algorithms
standardized by NIST until NIST finally managed to standardize Ed25519:

    https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fianix.com%2Fpub%2Fcurve25519-deployment.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C761537cbf2df453b870508dd4e873c30%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638753064916483179%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0SKQHCT7ngTPSEZPAiyookEpH0o7gYnyXJybftrY0l8%3D&reserved=0<https://ianix.com/pub/curve25519-deployment.html>
    https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fianix.com%2Fpub%2Fed25519-deployment.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C761537cbf2df453b870508dd4e873c30%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638753064916493712%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=gPtlUiI3gytlhezbXrJTaDsAw99H5vm%2BbWEeyZAQVpU%3D&reserved=0<https://ianix.com/pub/ed25519-deployment.html>
    https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fianix.com%2Fpub%2Fchacha-deployment.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C761537cbf2df453b870508dd4e873c30%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638753064916504255%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=76auLE569y51%2FU3wzBKFyRg1zdtoNMgoTI4kwHH3UzE%3D&reserved=0<https://ianix.com/pub/chacha-deployment.html>

Meanwhile one can also point to applications that mandate particular
NIST algorithms---such as NSA Suite B mandating P-384, _not_ P-256.

How is this complicated situation supposed to be an "apparent
convergence" on supporting "P256-AES-GCM and 25519-POLY-CHACHA", or,
more to the point, converging on "1 NIST and 1 non-NIST algorithm"?

These sound to me like controversial new policy proposals, giving NIST a
free pass into IETF rubber-stamping. These are very far from accurate
descriptions of "the history of how cryptographic components have been
documented and referenced in the IETF, particularly in RFCs", and even
farther from accurate descriptions of what is happening "outside IETF".

---D. J. Bernstein

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]