[saag] Re: [Ext] Re: draft-paulwh-crypto-components-02
"D. J. Bernstein" <[email protected]>
| Newsgroups | gmane.ietf.saag |
|---|---|
| Message-ID | <[email protected]> |
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://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://mailarchive.ietf.org/arch/msg/tls/pQRDJ9MBwnmLHp86Zvs_CfYUFaY/
https://mailarchive.ietf.org/arch/msg/tls/lWh_uimMIgQ6SMV_BSkJDh34eQM/
https://mailarchive.ietf.org/arch/msg/tls/vWAEg7E3jeLZjLABVaMVLR0flX4/
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://ianix.com/pub/curve25519-deployment.html
https://ianix.com/pub/ed25519-deployment.html
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]