[TLS] [Editorial Errata Reported] RFC6176 (5520)

RFC Errata System <rfc-editor@rfc-editor.org> Thu, 11 October 2018 13:19 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791A2130E6B for <tls@ietfa.amsl.com>; Thu, 11 Oct 2018 06:19:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXDyP2e9eP8l for <tls@ietfa.amsl.com>; Thu, 11 Oct 2018 06:19:32 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98AE8130DE4 for <tls@ietf.org>; Thu, 11 Oct 2018 06:19:32 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 0C996B8009D; Thu, 11 Oct 2018 06:19:14 -0700 (PDT)
To: turners@ieca.com, tim.polk@nist.gov, kaduk@mit.edu, ekr@rtfm.com, christopherwood07@gmail.com, joe@salowey.net, sean+ietf@sn3rd.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: eugene.adell@gmail.com, tls@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20181011131914.0C996B8009D@rfc-editor.org>
Date: Thu, 11 Oct 2018 06:19:14 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/jw8uGlInqQFzH1x3FyzkZTzFNWc>
Subject: [TLS] [Editorial Errata Reported] RFC6176 (5520)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Oct 2018 13:19:36 -0000

The following errata report has been submitted 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

--------------------------------------
Type: Editorial
Reported by: Eugene Adell <eugene.adell@gmail.com>

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.

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. 

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