Subject: [TLS] [Errata Rejected] RFC6176 (5520)

From: RFC Errata System <[email-masked]>
Date: Thu, 11 Oct 2018 06:26:41 -0700 (PDT)

The following errata report has been rejected for RFC6176,
"Prohibiting Secure Sockets Layer (SSL) Version 2.0".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5520

--------------------------------------
Status: Rejected
Type: Editorial

Reported by: Eugene Adell <[email-masked]>
Date Reported: 2018-10-11
Rejected by: EKR (IESG)

Section: 2

Original Text
-------------
   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.

Corrected Text
--------------
   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.

--------------------------------------
RFC6176 (draft-ietf-tls-ssl2-must-not-04)
--------------------------------------
Title               : Prohibiting Secure Sockets Layer (SSL) Version 2.0
Publication Date    : March 2011
Author(s)           : S. Turner, T. Polk
Category            : PROPOSED STANDARD
Source              : Transport Layer Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Eugène Adell <[email-masked]>
Date: Thu, 11 Oct 2018 16:49:29 +0200

Yes, I know the deficiencies list as reported in this document is not
exhaustive but it's worth mentionning this one even in a rejected errata.
It had a greater impact than the MITM reset, the latter being mentionned.

Le jeu. 11 oct. 2018 à 15:27, RFC Errata System <[email-masked]>
a écrit :

> 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--

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 11 Oct 2018 12:17:21 -0400

You will likely find
https://lists.w3.org/Archives/Public/ietf-http-wg/2018OctDec/0013.html
useful in explaining the process and purpose of errata, and what it means,
in practice, to update the document. This understanding will hopefully make
it clear why the errata was rejected.

On Thu, Oct 11, 2018 at 11:10 AM Eugène Adell <[email-masked]>
wrote:

>> 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
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Florian Weimer <[email-masked]>
Date: Tue, 16 Oct 2018 08:06:59 +0200

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

I think it's also historically incorrect.  More security problems were
caused by the ability to introduce arbitrary intermediate certificates
by CAs than by too many direct signing operations with a root CA key.
At least for web use, the original model (which does not allow
delegation of trust on the CA side) might actually have been more
approriate.  (On the RA side, delegation is of course technically
possible under any model, and it had its share of problems, too.)

---

From: Eugène Adell <[email-masked]>
Date: Wed, 17 Oct 2018 00:06:22 +0200

@Florian

The document is about the SSL 2.0 security deficiencies, particularly the
ones that brought its prohibition. The solutions to these deficiencies
might also have their own problems, as it's often the case in security
related topics which look like a never-ending debate (a problem, a
solution, a new problem), and they would logically be discussed in their
own threads or we would easily make anachronistic comments. The mitigation
of a root authority has a huge impact, and requires time to solve, that's
what said at that time, although it happened much later to some issuers.
In practice we see that direct signed certificates for Internet use were
abandoned, without anyone returning back to them. Also, the HSMs are
getting more widely used, and it gives more protection to the keying
material (which is an answer to the "overexposed keys").

@Ryan

Thanks. There's also that link
https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/ which is
almost saying the same. But at the same time RFC6176 is not exactly a
protocol description, it's a limited update to existing protocols that had
warned us this update would be published one day. Submitting an update for
a non technical part of this RFC doesn't make much sense too, maybe no more
than a rejected errata.