First, I think this is editorial. After all these years, I’m not really sure it’s an interop problem.
Second, if I were making this I would have placed the errata against RFC2712 where the values were assigned. It’s not really TLS1.2’s place to clear this up. spt > On Jun 26, 2018, at 08:28, 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: > http://www.rfc-editor.org/errata/eid5409 > > -------------------------------------- > Type: Technical > Reported by: Eugene Adell <eugene.ad...@gmail.com> > > Section: Appendix A.5 > > Original Text > ------------- > Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are > reserved to avoid collision with Fortezza-based cipher suites in > SSL 3. > > Corrected Text > -------------- > Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are > reserved to avoid collision with Fortezza-based cipher suites in > SSL 3. The cipher suite value { 0x00, 0x1E } firstly also assigned to > Fortezza has been released and has since been be reassigned. > > Notes > ----- > RFC 2712 (Addition of Kerberos Cipher Suites to Transport Layer Security) in > its Draft 01 version introduces three new cipher suites colliding with the > three Fortezza ones. The Draft 02 version partially corrects that, by moving > the Kerberos cipher suites values by two. > This omission of the third cipher suite has never been corrected, and this > remains in the same state in the final RFC 2712, RFC 2246 and its successors > including this one. > > Changing the first Kerberos cipher suite value, or moving all of them, would > now not make any sense. Enhancing the note as suggested is probably enough to > mention how one Fortezza cipher suite disappeared. > > 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
