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://www.rfc-editor.org/errata/eid6572 > > -------------------------------------- > 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://www.ietf.org/mailman/listinfo/tls
