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

Eugène Adell <eugene.adell@gmail.com> Thu, 11 October 2018 14:49 UTC

Return-Path: <eugene.adell@gmail.com>
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 1AC37130DD3; Thu, 11 Oct 2018 07:49:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Gv9qqvjY3kh0; Thu, 11 Oct 2018 07:49:50 -0700 (PDT)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 889F4126CC7; Thu, 11 Oct 2018 07:49:50 -0700 (PDT)
Received: by mail-wm1-x32d.google.com with SMTP id 143-v6so9239685wmf.1; Thu, 11 Oct 2018 07:49:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iz5IosGXpVeAwbSBwq1zV7m3t7HMb+xwp/rhELUbM+E=; b=n8BqNq+vkFGKKHjPmg3+85+IrhCn1Vu4Kolv6DD49BA1T8GkRVK/jMTDU588N5Y990 RUeAy7nHtcSha0E98tQ9PDc/ZBk6OBRqbX84UHDEN8r9WAYtb+vKT30zwn4COmtK1NaH NV/9qNDp/vSH8IPuQWYewzLYv7dPmLDyG0BJ61dZ7yeA4um4wTPo6UrJauH1xE1WvDnY /fCruXyStB6udHJkbZsuCgBBtgYWlsrnuYBOrmAtPN7Z3/Ce2zXQHGDRIsGen0e4oOtl JIXME14sGHi5JAmdI3RSDBxd4AnK3Zl4JV9dpNxZaXWxSMvJG7Bejsjy27A3kM67w3mI gxWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iz5IosGXpVeAwbSBwq1zV7m3t7HMb+xwp/rhELUbM+E=; b=H52EUnZ1rvKxsvW2YKuaVZ7SCasWPwYvuw5Q3p2wjDbz9s7XwxzDDiwMmRi0MWgIiF /X55IMNdz1befuWeJpgv07zHp6G08BuskV/4YRAlQKe72dbfP+q1JMQ64/H2CvN69MXz /FilvOwefyAP40UBeK5yVNiFGUF8aku3PoPwU04mT/kRFrI6gfyKYBobWFMQqK/TeBq3 q18y3K5SCAhPAQXqXmCgy/5D+iQ7GARgSpCZrWs62Eiyc6B7dzDgfwj0yKwg1+dOEnPN lVvoYD6piWVNEVRyij+mKyJgLrkljzeTCC/nPwiEhmGT6ct64yyHyIKKrOx8iwxQm0fV UR4Q==
X-Gm-Message-State: ABuFfohD3hKj3s40RjU790oHkyKB+uDPNEEeErt+TNzJmq9nz8yMbJ7B B05PwUPZjj3X1itPX7p3bzjuMhydVBoxTQq4OsQ=
X-Google-Smtp-Source: ACcGV633b4ZYM/2u/TPY4nrYS8EQ1EaFO6rVmZIgwK+9T07kJ7doPISgzWfqej1MJQlvPmN+CdYV+jli3XGkevyD3n8=
X-Received: by 2002:a1c:8154:: with SMTP id c81-v6mr1961574wmd.140.1539269388968; Thu, 11 Oct 2018 07:49:48 -0700 (PDT)
MIME-Version: 1.0
References: <20181011132641.BC838B804DC@rfc-editor.org>
In-Reply-To: <20181011132641.BC838B804DC@rfc-editor.org>
From: =?UTF-8?Q?Eug=C3=A8ne_Adell?= <eugene.adell@gmail.com>
Date: Thu, 11 Oct 2018 16:49:29 +0200
Message-ID: <CALY=zUeRsqBwBbaqeDAvt-gpJ1jRO2bfEohckyou8aEYkgrL5Q@mail.gmail.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: turners@ieca.com, tim.polk@nist.gov, Eric Rescorla <ekr@rtfm.com>, iesg@ietf.org, TLS WG <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000024a7cc0577f51526"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/vqpv-6-CVTCGv2H9UK7TWC3qGWA>
X-Mailman-Approved-At: Thu, 11 Oct 2018 08:10:20 -0700
Subject: Re: [TLS] [Errata Rejected] 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 14:49:53 -0000

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 <rfc-editor@rfc-editor.org>;
a écrit :

> 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 <eugene.adell@gmail.com>;
> 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
>