...@rtfm.com; r...@cert.org; ka...@mit.edu;
c...@heapingbits.net; j...@salowey.net; sean+i...@sn3rd.com
Cc: rfc-edi...@rfc-editor.org; tls@ietf.org; johannes.goerl...@siemens.com
Subject: [TLS] [Technical Errata Reported] RFC5246 (6572)
The following errata report has been submitted for RFC5246
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
> di
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 -
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. Ra
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
Re
