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

Ryan Sleevi <ryan-ietftls@sleevi.com> Thu, 11 October 2018 16:17 UTC

Return-Path: <ryan.sleevi@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 CE440130E1B; Thu, 11 Oct 2018 09:17:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 p91hzQ2TGziZ; Thu, 11 Oct 2018 09:17:35 -0700 (PDT)
Received: from mail-it1-f176.google.com (mail-it1-f176.google.com [209.85.166.176]) (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 0998C130EB9; Thu, 11 Oct 2018 09:17:35 -0700 (PDT)
Received: by mail-it1-f176.google.com with SMTP id q70-v6so14359910itb.3; Thu, 11 Oct 2018 09:17:35 -0700 (PDT)
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=2Ic2RubtslVXnAIkIKooxzK6Et/wko+iid7vBN0HL5s=; b=Ce91vqBN7do44fgmth1kcbHtKD29DmdgBLIfkHUyfWXBVkmstkLrS7VlKLThY2qNFw 9xoL0Zm6zHbdxeb+y/QtZHtyarJA1wBddl8MlgEfqw5c6ecukGAXqLOWyPn3rFJjJdtx COUw/znjp3z6OrJ/3ii1TRBw0DRDDMc/OD7qypgWHCqSMkpwQmUhiDXHctFkXp4gAq3O 8o64rRpKpe1K84vuJX+agxYtar/sIkJj9rRnGmVIvPgeaKCA0gglK4/HwsFHRvcvQu3M H9yCwDX3n3WuvqG3RutIZBNFeGWiKU4VmQG6j7wmsgDHOvLHHgEDC5497Uh66Szai3l+ NxMw==
X-Gm-Message-State: ABuFfoiQEzjkIoDkOATOZQaYriJ3iAbq+d/QCv1JAoG72AnHoO8KZas9 lM+TjyqYtvMr1G1pDQNJclGPQyaM9LTZPA==
X-Google-Smtp-Source: ACcGV60w9+olKGnodC9AVUMEl+QYdXhEGS727wR0FliicdsG0aPDxIHdsA6Bqs/8FpxY+8QubDrthQ==
X-Received: by 2002:a24:9:: with SMTP id 9-v6mr1878302ita.35.1539274654078; Thu, 11 Oct 2018 09:17:34 -0700 (PDT)
Received: from mail-it1-f173.google.com (mail-it1-f173.google.com. [209.85.166.173]) by smtp.gmail.com with ESMTPSA id n5-v6sm6203938ioh.58.2018.10.11.09.17.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Oct 2018 09:17:33 -0700 (PDT)
Received: by mail-it1-f173.google.com with SMTP id 134-v6so14367163itz.2; Thu, 11 Oct 2018 09:17:33 -0700 (PDT)
X-Received: by 2002:a02:9bc6:: with SMTP id f6-v6mr1747829jal.114.1539274652860; Thu, 11 Oct 2018 09:17:32 -0700 (PDT)
MIME-Version: 1.0
References: <20181011132641.BC838B804DC@rfc-editor.org> <CALY=zUeRsqBwBbaqeDAvt-gpJ1jRO2bfEohckyou8aEYkgrL5Q@mail.gmail.com>
In-Reply-To: <CALY=zUeRsqBwBbaqeDAvt-gpJ1jRO2bfEohckyou8aEYkgrL5Q@mail.gmail.com>
From: Ryan Sleevi <ryan-ietftls@sleevi.com>
Date: Thu, 11 Oct 2018 12:17:21 -0400
X-Gmail-Original-Message-ID: <CAErg=HFs2=Sed0=z0xFPAS3=0BaFcAYLmiuPaBuiqK1UWq_Keg@mail.gmail.com>
Message-ID: <CAErg=HFs2=Sed0=z0xFPAS3=0BaFcAYLmiuPaBuiqK1UWq_Keg@mail.gmail.com>
To: eugene.adell@gmail.com
Cc: rfc-editor@rfc-editor.org, tim.polk@nist.gov, turners@ieca.com, "tls@ietf.org" <tls@ietf.org>, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e547eb0577f64ee9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/mZZoarLBcrY5JWYpPglVEIKLGgU>
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 16:17:37 -0000

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

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