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

Nick Sullivan <nick@cloudflare.com> Fri, 14 February 2020 19:38 UTC

Return-Path: <nick@cloudflare.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 3B8F1120B81 for <tls@ietfa.amsl.com>; Fri, 14 Feb 2020 11:38:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 vnOWlI93-zdV for <tls@ietfa.amsl.com>; Fri, 14 Feb 2020 11:38:04 -0800 (PST)
Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 B3265120B50 for <tls@ietf.org>; Fri, 14 Feb 2020 11:38:03 -0800 (PST)
Received: by mail-vs1-xe29.google.com with SMTP id x123so6972199vsc.2 for <tls@ietf.org>; Fri, 14 Feb 2020 11:38:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6w41Kb6sUns/vji5FKqw5CFpbPoYM+wK13mZAb5Cj4U=; b=HQH+AzZGy7nDCOhOVz67CaAdWOr3eYCB88+4EifEavcPSZVhl+65NEJtHlVIa56cTM 0R3CzfSMdrX5uSSJXcLhhxrKqv1U0rwSCb38MDkbeZUIl/JNkPbFOT9nAV1hfvd2uNKy xJgIIfYQTcfv+B2ObVxJDDr9dFPHTa80if/+A=
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=6w41Kb6sUns/vji5FKqw5CFpbPoYM+wK13mZAb5Cj4U=; b=iJy8fXNcO4ZLJ8fAMynggGGX9Y22jQhVQRKUtZBZfIxGFAv8eSYXfaoMkvhGmXDD0f Y9FVWoxfSDLASnDWta59QQoO5yxD/CMAn9bOo6Zi9FbsxtDcY75UixErticIvfyWvJBn b0R04u7FyAHLQVXkAjD+K5FQOBhwFxyGJ0S+ZFiNpP4B5uXnvTFrsLcRoPxcHZzuyo/2 vKeTFgPBPszaqZnXOAr8Qr4uiS9KUEeTsrjsx1E95B8i4YsW+qu+3Q8LApbR/+c/1PNA wFwX4AvdTzeUdLtOc0hU0AlbqM5HKcujcV8LQeQyHlxMMcFfLJV/wgB0oK4MrZ+8nK8f O/DA==
X-Gm-Message-State: APjAAAW0BvgucKzQXfw6tij3fv4PWaOG6S0jnXhCcSF/Dfp66ZtIPIo0 F34h6PziAWdX34ZXzstVh0/fvvD40XFaw5N72/DTPA==
X-Google-Smtp-Source: APXvYqy1QVZfVKUttXusIJDLr/iV74YvlEd+qtmizhZ/SdujsxYK98V7YQehU2tAIOzi/GxCi4iD0IhSEFDxukBsf7I=
X-Received: by 2002:a67:f1ca:: with SMTP id v10mr2491262vsm.180.1581709082547; Fri, 14 Feb 2020 11:38:02 -0800 (PST)
MIME-Version: 1.0
References: <158093501262.12877.10966121264461280401@ietfa.amsl.com> <45495A4A-F79D-49B3-9887-3BFF00C00589@icloud.com>
In-Reply-To: <45495A4A-F79D-49B3-9887-3BFF00C00589@icloud.com>
From: Nick Sullivan <nick@cloudflare.com>
Date: Fri, 14 Feb 2020 11:36:40 -0800
Message-ID: <CAFDDyk_ZUQpJVj6Hv584vFFgJuzEH+tHYmqrX68e=LwK_rndbA@mail.gmail.com>
To: Carrick Bartle <cbartle891=40icloud.com@dmarc.ietf.org>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000000f63d059e8e586e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/FvuoLJMzUGzqLyq8K_eQ61mZhw8>
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: Fri, 14 Feb 2020 19:38:14 -0000

Carrick,

Thank you for reading the document and identifying an embarrassingly
difficult to parse motivating paragraph (with an annoying unclosed
parenthesis to boot). You've correctly identified the meaning it was trying
to convey and we'll happily review this as a PR here:
https://github.com/tlswg/tls-subcerts/. I've noticed a few other
readability issues in the document, if you find anything else, we'll
happily look at those too.

Nick

On Thu, Feb 13, 2020 at 3:46 PM Carrick Bartle <cbartle891=
40icloud.com@dmarc.ietf.org> wrote:

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