On Fri, Aug 31, 2018 at 01:46:24PM -0400, Richard Barnes wrote:
> On Fri, Aug 31, 2018 at 1:39 PM Benjamin Kaduk <ka...@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 mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
