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
- [Acme] Benjamin Kaduk's Discuss on draft-ietf-acm… Benjamin Kaduk
- Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf… Richard Barnes
- Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf… Ben Campbell
- Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf… Alexey Melnikov
- Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf… Richard Barnes
- Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf… Richard Barnes
- Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf… Daniel McCarney
- Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf… Felix Fontein
- Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf… Felix Fontein
- Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf… Daniel McCarney
- Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- [Acme] lack of nonce for external account binding… Benjamin Kaduk
- Re: [Acme] lack of nonce for external account bin… Richard Barnes
- Re: [Acme] lack of nonce for external account bin… Benjamin Kaduk
- Re: [Acme] lack of nonce for external account bin… Richard Barnes
- Re: [Acme] lack of nonce for external account bin… Salz, Rich