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

Florian Weimer <fw@deneb.enyo.de> Tue, 16 October 2018 06:12 UTC

Return-Path: <fw@deneb.enyo.de>
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 021DA1292AD; Mon, 15 Oct 2018 23:12:50 -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] 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 C3P-YqgfNS1a; Mon, 15 Oct 2018 23:12:47 -0700 (PDT)
Received: from albireo.enyo.de (albireo.enyo.de [5.158.152.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF211277D2; Mon, 15 Oct 2018 23:12:46 -0700 (PDT)
Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gCIau-0002hl-PH; Tue, 16 Oct 2018 06:12:40 +0000
Received: from fw by deneb.enyo.de with local (Exim 4.89) (envelope-from <fw@deneb.enyo.de>) id 1gCIVP-00041e-Hf; Tue, 16 Oct 2018 08:06:59 +0200
From: Florian Weimer <fw@deneb.enyo.de>
To: eugene.adell@gmail.com, turners@ieca.com, tim.polk@nist.gov, iesg@ietf.org, tls@ietf.org
References: <20181011132641.BC838B804DC@rfc-editor.org>
Date: Tue, 16 Oct 2018 08:06:59 +0200
In-Reply-To: <20181011132641.BC838B804DC@rfc-editor.org> (RFC Errata System's message of "Thu, 11 Oct 2018 06:26:41 -0700 (PDT)")
Message-ID: <87va62zapo.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kCKusA95U73AMTYyesNicBlHoK0>
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: Tue, 16 Oct 2018 06:12:50 -0000

* RFC Errata System:

> Corrected Text
> --------------

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

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