Re: [TLS] [Technical Errata Reported] RFC5246 (6572)

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-editor@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.goerlich@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$ 