Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt

Carrick Bartle <cbartle891@icloud.com> Thu, 13 February 2020 23:45 UTC

Return-Path: <cbartle891@icloud.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 D0228120026 for <tls@ietfa.amsl.com>; Thu, 13 Feb 2020 15:45:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 4gYqeKwkCAa2 for <tls@ietfa.amsl.com>; Thu, 13 Feb 2020 15:45:52 -0800 (PST)
Received: from mr85p00im-zteg06021601.me.com (mr85p00im-zteg06021601.me.com [17.58.23.187]) (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 3D211120020 for <tls@ietf.org>; Thu, 13 Feb 2020 15:45:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1581637551; bh=oq3+7dQ0lUkD9krDkXywRmm8Cns0cFG2F4X5FuLKvsI=; h=From:Content-Type:Subject:Date:To:Message-Id; b=JHVg8qeOMdt6WRG6RfiTV7HxXG09F6sop6htO51Atkm0ARTKWhzvLy+uj5Xsgbrut +8gGKNuvj2JgiQ0+7C+hPSltQo9Iyek25AF8XTtvvI6nhlCmlejkAlX+INQzHQlHfv AVPdl+DgGgE9egLEXlGk/q6hpXgk81EWdMLF01wJcWu7IABGMBfUJY47PSkDuEKa/3 yae6AfkVjSzD8z3CZ5ixwQ+9urDNmPArIi4uYjlSyb4CA9yVaSjRSOkuEnZu0Ygx6v mjQcfhKf2IUFoJn3xQtUFQ+gsZfqkLGXBBPKO4FvCWwDQcIbGvXXyvmR2+VYKHQgwU JLed9eaj2Wm7w==
Received: from [17.230.167.54] (unknown [17.230.167.54]) by mr85p00im-zteg06021601.me.com (Postfix) with ESMTPSA id A85B44002AC for <tls@ietf.org>; Thu, 13 Feb 2020 23:45:51 +0000 (UTC)
From: Carrick Bartle <cbartle891@icloud.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.3\))
Date: Thu, 13 Feb 2020 15:45:50 -0800
References: <158093501262.12877.10966121264461280401@ietfa.amsl.com>
To: tls@ietf.org
In-Reply-To: <158093501262.12877.10966121264461280401@ietfa.amsl.com>
Message-Id: <45495A4A-F79D-49B3-9887-3BFF00C00589@icloud.com>
X-Mailer: Apple Mail (2.3608.80.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-13_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-2002130172
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/jsnBgLRzD1yUri4owSi0w5_bj7Y>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt
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, 13 Feb 2020 23:45:54 -0000

TL;DR: I find it difficult to understand the second-to-last paragraph of the Introduction, so I took a stab at revising it. Let me know if I should put it in a pull request.


This is the paragraph I'm referring to:

"These dependencies cause problems in practice. Server operators often want to create short-lived certificates for servers in low- trust zones such as Content Delivery Network (CDNs) or remote data centers. This allows server operators to limit the exposure of keys in cases that they do not realize a compromise has occurred. The risk inherent in cross-organizational transactions makes it operationally infeasible to rely on an external CA for such short- lived credentials. In Online Certificate Status Protocol (OCSP) stapling (i.e., using the Certificate Status extension type ocsp [RFC8446], if an operator chooses to talk frequently to the CA to obtain stapled responses, then failure to fetch an OCSP stapled response results only in degraded performance. On the other hand, failure to fetch a potentially large number of short lived certificates would result in the service not being available, which creates greater operational risk."

Here are my issues with it:

- I think OCSP is being brought up here as an example of a way that dependence on a CA can go wrong, but that isn't really made explicit.

- I'm not sure what "only" means in "only in degraded performance." Is it "the worst that can happen is just degraded performance" or "it can result only in degraded performance, as opposed to better performance"? At first I thought it was the latter, but after reading the subsequent sentence, I realized it was probably the former.

- The use of "On the other hand" sounds like the rest of the sentence is going to describe a way that failure to receive something from a CA resulted in better performance, which obviously would be silly.

Taking all these points together, here's my suggestion for a revision to make what I think the thrust of the paragraph is more clear:

"These dependencies cause problems in practice. Server operators often want to create short-lived certificates for servers in low-trust zones such as Content Delivery Network (CDNs) or remote data centers. This allows server operators to limit the exposure of keys in cases where they do not realize a compromise has occurred. But the risk inherent in cross-organizational transactions makes it operationally infeasible to rely on an external CA for such short-lived credentials. For instance, in the case of Online Certificate Status Protocol (OCSP) stapling (i.e., using the Certificate Status extension type ocsp [RFC8446]), a CA may fail to deliver OCSP stapled response. While this will result in degraded performance, the ramifications of failing to deliver short-lived certificates is even worse: the service that depends on those certificates would go down entirely. Thus, ensuring independence from CAs for short-lived certificates is critical to the uptime of a service."


Carrick



> On Feb 5, 2020, at 12:36 PM, internet-drafts@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
> 
>        Title           : Delegated Credentials for TLS
>        Authors         : Richard Barnes
>                          Subodh Iyengar
>                          Nick Sullivan
>                          Eric Rescorla
> 	Filename        : draft-ietf-tls-subcerts-06.txt
> 	Pages           : 15
> 	Date            : 2020-02-05
> 
> Abstract:
>   The organizational separation between the operator of a TLS endpoint
>   and the certification authority can create limitations.  For example,
>   the lifetime of certificates, how they may be used, and the
>   algorithms they support are ultimately determined by the
>   certification authority.  This document describes a mechanism by
>   which operators may delegate their own credentials for use in TLS,
>   without breaking compatibility with peers that do not support this
>   specification.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tls-subcerts-06
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-06
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-06
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls