Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Fri, 31 August 2018 17:51 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2868D12D7F8; Fri, 31 Aug 2018 10:51:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 kCppvBSOvAWy; Fri, 31 Aug 2018 10:51:54 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 70870128CFD; Fri, 31 Aug 2018 10:51:53 -0700 (PDT)
X-AuditID: 1209190f-eb7ff70000001acf-5b-5b89800da974
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 21.B8.06863.E00898B5; Fri, 31 Aug 2018 13:51:10 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w7VHp5HE014839; Fri, 31 Aug 2018 13:51:06 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w7VHp00C001074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 31 Aug 2018 13:51:03 -0400
Date: Fri, 31 Aug 2018 12:51:00 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Richard Barnes <rlb@ipv.sx>
Cc: The IESG <iesg@ietf.org>, draft-ietf-acme-acme@ietf.org, Yoav Nir <ynir.ietf@gmail.com>, "<acme-chairs@ietf.org>" <acme-chairs@ietf.org>, IETF ACME <acme@ietf.org>
Message-ID: <20180831175100.GR15624@kduck.kaduk.org>
References: <153556883241.14872.599302420878484743.idtracker@ietfa.amsl.com> <CAL02cgQoC1YAA1wjftoFSMBfm7Vi4KUXUQW633GZ5tM9VMMrmg@mail.gmail.com> <20180831000615.GF15624@kduck.kaduk.org> <CAL02cgShYM39aVn0CT2UJFrVSxjvN8VTd9YdSe8yvjFdqnrXmA@mail.gmail.com> <20180831173933.GP15624@kduck.kaduk.org> <CAL02cgR2v4+dWXW=ztm4rqcgZVZcn3Zv51xbL59fe3cr2p5gGg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAL02cgR2v4+dWXW=ztm4rqcgZVZcn3Zv51xbL59fe3cr2p5gGg@mail.gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT0eVr6Iw22HlKzmL/61lMFqueB1os 3M5mMePPRGaLqX22FkuPfWByYPPYOesuu8eSJT+ZPCZvnMUSwBzFZZOSmpNZllqkb5fAlXFr tX5Bk2jFluPTWBsYFwh0MXJwSAiYSHTdV+5i5OIQEljMJNG+fwMThLORUWLy94WMEM5VJolv Gx8CZTg5WARUJQ786GMDsdkEVCQaui8zg9giAvISp68/YAVpYBY4xChxYepcVpCEsECcxITZ t1hAbF6gdd92HGaGmPqdSWLnhx3MEAlBiZMzn4AVMQtoSdz495IJ5D5mAWmJ5f84QMKcAoES 69/9YgSxRQWUJfb2HWKfwCgwC0n3LCTdsxC6FzAyr2KUTcmt0s1NzMwpTk3WLU5OzMtLLdI1 0cvNLNFLTSndxAgKaU5J/h2Mcxq8DzEKcDAq8fDecOqMFmJNLCuuzD3EKMnBpCTK61cGFOJL yk+pzEgszogvKs1JLQZ6loNZSYSXM6MjWog3JbGyKrUoHyYlzcGiJM7reK41WkggPbEkNTs1 tSC1CCYrw8GhJMErUg80VLAoNT21Ii0zpwQhzcTBCTKcB2i4AUgNb3FBYm5xZjpE/hSjLsef 91MnMQux5OXnpUqJ85rWARUJgBRllObBzQGlIons/TWvGMWB3hLmbQGp4gGmMbhJr4CWMAEt YbkK8kFxSSJCSqqB0aRa336+36Vdu6dybHTPOHjMWDL4l6WRzbGrjROsf2zSNZD1cQv5wHkw ePaf6F/yke3Hq/enJNZJGpnviFHcYDR9g0Nv44QamVurV/EFJz1+xZ+TGfzv4KySWWltlW3T 1+/9qt7DWqJ261VGYGqwXNeRC0H/thgaNSzo61rf8eaE0++T3678UWIpzkg01GIuKk4EAPmT tKYgAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/BROwU5sry4WUHSC2w0snHKCB8Xs>
Subject: Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Aug 2018 17:51:58 -0000

On Fri, Aug 31, 2018 at 01:46:24PM -0400, Richard Barnes wrote:
> On Fri, Aug 31, 2018 at 1:39 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> > On Fri, Aug 31, 2018 at 12:32:08PM -0400, Richard Barnes wrote:
> > >
> > > > Do you want to mention that the caaIdentities element gives a leaf cert
> > > > some control over the trust anchors that are used, in the security
> > > > considerations?  (This is a serious question; I am leaning towards it
> > being
> > > > worth doing, but it would not be very hard to convince me otherwise.)
> > > >
> > >
> > > I'm not sure what you mean by "caaIdentities element gives a leaf cert
> > some
> > > control over the trust anchors that are used".  Who is controlling whose
> > > use of trust anchors, and how?
> >
> > The scenario I had in mind, which may be completely bogus, was that you
> > have a CDN/whatever in front of the ACME server; that CDN's EE cert could
> > in principle be signed by a different CA hierarchy than the ACME server is
> > doing issuance for.  So you have a TLS cert from CA XYZ that is the
> > authentication on a statement "use CAA value <foo> for CA ABC".  If the
> > ACME
> > client and its friends then go off and installs <foo> as their CAA record
> > with a large TTL, when the client goes to ask for a cert, ABC goes and
> > checks the CAA record and says "nothing doing".  If ABC caches for the full
> > TTL, the client might have to find a different CA (perhaps one that does
> > not use an actively harmful CDN to front its operations, heh).  This seems
> > to only differ from the case of a CDN just dropping traffic on the floor or
> > the other DoS vectors available to it, by virtue of the long TTL on the CAA
> > record -- even after ABC decides that this CDN is evil and switches, that
> > bogus CAA record is still valid.  Maybe it's better to say that the CDN's
> > EE cert is controlling which trust anchor is *not* used [for issuing
> > certificates for the client's domain] than to say it controls which trust
> > anchor is used.
> >
> 
> I agree that the TTL is the only issue here, and I don't think even that's
> an issue.  RFC 6844 already requires CAs to be self-reliant and do their
> own recursing ("Data cached by third parties MUST NOT be relied on"), so
> they won't be stuck behind someone else's cache.  And it seems like CAs
> have an incentive to get fresh data, since if they don't issue because of a
> bad cached CAA record, they're losing business.
> 
> So I don't think there's anything to resolve here.

If you think that the CA will be willing to ignore its local cache and
re-fetch, I'm okay with dropping this topic.

-Benjamin