I agree that this isn't an appropriate change for an erratum. Even with a new RFC updating RFC 5246, we'd still need to have some discussion about a transition plan, at which point just relying on the guidance in BCP 195 becomes more and more attractive.
-Ben On Wed, May 05, 2021 at 04:00:00PM -0700, Eric Rescorla wrote: > I'm not sure precisely what attacks you are referring to here. In > particular, I'm not aware of any known security issues with HMAC-SHA1. With > that said, I agree that we wouldn't choose AES_128_CBC_SHA as a default > now, but this isn't usually the kind of thing we would usually use an > erratum for. Rather, this would be appropriate for a new RFC updating 5246. > > -Ekr > > > On Wed, May 5, 2021 at 3:21 AM RFC Errata System <rfc-edi...@rfc-editor.org> > wrote: > > > The following errata report has been submitted for RFC5246, > > "The Transport Layer Security (TLS) Protocol Version 1.2". > > > > -------------------------------------- > > You may review the report below and at: > > https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6572__;!!GjvTz_vk!FfdA-HJa47sbeeDEDwh3TNDNxVmLXLJdZQ-bzn4yM_KdLFt6kEcEiWduzMMlqw$ > > > > > > -------------------------------------- > > Type: Technical > > Reported by: Johannes Görlich <johannes.goerl...@siemens.com> > > > > Section: 9 > > > > Original Text > > ------------- > > In the absence of an application profile standard specifying otherwise, a > > TLS-compliant application MUST implement the cipher suite > > TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the definition). > > > > Corrected Text > > -------------- > > In the absence of an application profile standard specifying otherwise, a > > TLS-compliant application MUST implement the cipher suite > > TLS_RSA_WITH_AES_128_GCM_SHA256 (see Appendix A.5 for the definition). > > > > Notes > > ----- > > A must-be-implement cipher suite should not relay on a bulk encryption > > algorithm which is vulnerable to plain-text attacks or on a secure hash > > algorithm which has been proven to be insecure. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC5246 (draft-ietf-tls-rfc4346-bis-10) > > -------------------------------------- > > Title : The Transport Layer Security (TLS) Protocol Version > > 1.2 > > Publication Date : August 2008 > > Author(s) : T. Dierks, E. Rescorla > > Category : PROPOSED STANDARD > > Source : Transport Layer Security > > Area : Security > > Stream : IETF > > Verifying Party : IESG > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!FfdA-HJa47sbeeDEDwh3TNDNxVmLXLJdZQ-bzn4yM_KdLFt6kEcEiWd4LHbbkQ$ > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
