Given that RFC 5246 is obsolete, all of this is largely moot. I think that we can reject this erratum.
On Thu, May 6, 2021, at 09:06, Benjamin Kaduk wrote: > 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 > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
