Hi Loganaden, Thanks for the info! I think this shows that also under the old RFC8447 definition of “generally recommended for implementations to support” the “Y” classification was wrong.
Cheers, John From: Loganaden Velvindron <logana...@gmail.com> Date: Wednesday, 11 January 2023 at 20:31 To: John Mattsson <john.matts...@ericsson.com> Cc: TLS@ietf.org <tls@ietf.org> Subject: Re: [TLS] FW: New Version Notification for draft-mattsson-tls-psk-ke-dont-dont-dont-04.txt Hi John, On Wed, Jan 11, 2023, 21:49 John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org<mailto:40ericsson....@dmarc.ietf.org>> wrote: Hi, Changes in -04: - Eric Rescorla commented that we should ask whether it's time to deprecate or at least Discourage psk_ke. Changed the psk_ke suggestion from “N” to “D” - Added that BoringSSL has chosen to not even implement psk_ke I've also looked at LibreSSL quickly and it doesn't appear to support psk_ke in their TLS 1.3 stack. - Eric Rescorla commented that he thinks the RFC 9150 algorithms should be marked as Discouraged. The document was updated with an evaluation and this suggestion. - The x25519 performance section was rewritten after a comment from Paul Wouters - Added evaluations and suggestions for the other TLS 1.3 parameters (ffdhe2048, rsa_pkcs1_sha256, rsa_pkcs1_sha384, and rsa_pkcs1_sha512) that BSI has introduced deadlines for. - Changed to standards track as the suggested IANA actions require Standards Action - Added introduction to explain RFC8447 and RFC8447bis - Added details on exactly which zero trust principles that are intended (comment from Eric Rescorla) Cheers, John From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> Date: Wednesday, 11 January 2023 at 18:24 To: John Mattsson <john.matts...@ericsson.com<mailto:john.matts...@ericsson.com>>, John Mattsson <john.matts...@ericsson.com<mailto:john.matts...@ericsson.com>> Subject: New Version Notification for draft-mattsson-tls-psk-ke-dont-dont-dont-04.txt A new version of I-D, draft-mattsson-tls-psk-ke-dont-dont-dont-04.txt has been successfully submitted by John Preuß Mattsson and posted to the IETF repository. Name: draft-mattsson-tls-psk-ke-dont-dont-dont Revision: 04 Title: NULL Encryption and Key Exchange Without Forward Secrecy are Dicouraged Document date: 2023-01-11 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-04.txt Status: https://datatracker.ietf.org/doc/draft-mattsson-tls-psk-ke-dont-dont-dont/ Html: https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-04.html Htmlized: https://datatracker.ietf.org/doc/html/draft-mattsson-tls-psk-ke-dont-dont-dont Diff: https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-psk-ke-dont-dont-dont-04 Abstract: Massive pervasive monitoring attacks using key exfiltration and made possible by key exchange without forward secrecy have been reported. If key exchange without Diffie-Hellman is used, static exfiltration of the long-term authentication keys enables passive attackers to compromise all past and future connections. Malicious actors can get access to long-term keys in different ways: physical attacks, hacking, social engineering attacks, espionage, or by simply demanding access to keying material with or without a court order. Exfiltration attacks are a major cybersecurity threat. If NULL encryption is used an on-path attacker can read all application data. The use of psk_ke and NULL encryption are not following zero trust principles of minimizing the impact of breach and governments have already made deadlines for their deprecation. This document sets the Recommended values of psk_ke, TLS_SHA256_SHA256, TLS_SHA384_SHA384, ffdhe2048 to "D" and the Recommended values of rsa_pkcs1_sha256, rsa_pkcs1_sha384, and rsa_pkcs1_sha512 to "N". The IETF Secretariat _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
