RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Reported (1)

RFC 6176, "Prohibiting Secure Sockets Layer (SSL) Version 2.0", March 2011

Source of RFC: tls (sec)

Errata ID: 5536
Status: Reported
Type: Editorial

Reported By: Eugene Adell
Date Reported: 2018-10-19

Section 1 says:

   RFC 4346 [TLS1.1], and later RFC 5246 [TLS1.2], explicitly warned
   implementers that the "ability to send version 2.0 CLIENT-HELLO
   messages will be phased out with all due haste".  This document
   accomplishes this by updating the backward compatibility sections
   found in TLS [TLS1.0][TLS1.1][TLS1.2].

It should say:

   RFC 2246 [TLS1.0], and later RFC 4346 [TLS1.1], then RFC 5246
   [TLS1.2] explicitly warned implementers that the "ability to send
   version 2.0 CLIENT-HELLO messages will be phased out with all due
   haste". This document accomplishes this by updating the backward
   compatibility sections found in TLS [TLS1.0][TLS1.1][TLS1.2].

Notes:

The warning on the version 2.0 Client Hello is as old as the first TLS version (RFC 2246 Appendix E). That's what the authors meant and wanted to highlight by listing two of the three RFCs containing this warning. This is confirmed by their last sentence. It looks like a small mistake without concrete effects, I push this errata considering "IESG Processing of RFC Errata for the IETF Stream rule 6"

Status: Rejected (1)

RFC 6176, "Prohibiting Secure Sockets Layer (SSL) Version 2.0", March 2011

Source of RFC: tls (sec)

Errata ID: 5520
Status: Rejected
Type: Editorial

Reported By: Eugene Adell
Date Reported: 2018-10-11
Rejected by: EKR
Date Rejected: 2018-10-11

Section 2 says:

   o  Sessions can be easily terminated.  A man-in-the-middle can easily
      insert a TCP FIN to close the session, and the peer is unable to
      determine whether or not it was a legitimate end of the session.

It should say:

   o  Sessions can be easily terminated.  A man-in-the-middle can easily
      insert a TCP FIN to close the session, and the peer is unable to
      determine whether or not it was a legitimate end of the session.

   o  The root certificate authority keys are overexposed. The server
      sends only one certificate signed by a root certificate authority,
      which means a frequent use of this authority keys for signing new
      certificates. This use can lead to key loss and the compromise of
      all certificates previously signed including the root certificate.

Notes:

Adding a deficiency.
Recent history showed that well-known authorities could loose their keys and it had a wide impact on security.
SSL 2.0 limits the certificate handshake message to one single certificate, thus making it impossible to send a certificate chain.
A certificate chain doesn't completely prevent key loss, but it gives more protection to the root certificate keys which can be stored and hidden until we need them again, which is much less often than without chaining.



--VERIFIER NOTES--
This isn't an error in the original document. It's new text you want to add.

Report New Errata