Subject: [Acme] CAA account key binding PR

From: Hugo Landau <[email-masked]>
Date: Mon, 22 Feb 2016 18:59:43 +0000

I've published my previous proposal for ACME account key thumbprint
binding via CAA records as a pull request.

<https://github.com/ietf-wg-acme/acme/pull/85>

An implementation for this functionality is now available as a patch
against boulder.

<https://github.com/letsencrypt/boulder/pull/1486>

Comments welcome.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 26 Feb 2016 10:06:08 -0800

First question: Do we want to bind the account key thumbprint, or the
account (registration) URL? In the latter case, an entity that rotates
their account key periodically doesn't have to update DNS at the same time.

I see two use cases for this:

1. A domain admin with subdomains pointed at web servers operated by
other people, who wants to prevent the web server operators from issuing
certificates independently. For instance, large IT departments might
want this.

Note: if DNS administration is delegated instead of web server
operation, this doesn't work, because CAA records are evaluated from
subdomain to parent domain. So the subdomain operator could provision a
CAA record overriding the parent one. Arguably this is correct, since
delegating DNS is more "powerful" than delegating web server operation,
but it might be surprising to some.

2. Avoiding the inherent risks of DV. Under DV, someone who controls DNS
or the network can fake authorization for any domain they want. With
account key binding, the domain admin could restrict issuance to a
specific ACME account, removing the risk of network control.

However, since CAA is delivered over DNS, we still haven't solved that
problem. I think if we want to solve (2), we need to add some more
specifics about *when* the CAA record is checked, how long it is
considered valid for, and how, if at all, the domain owner can change
the binding in case they accidentally lock themselves out, or in case a
service provider (like a CDN) configured an account key binding, but the
domain owner wants to change it.

Am I missing a use case? Also, open question: is CAA definitely the
right place to implement this?

Thanks,
Jacob

On 02/22/2016 10:59 AM, Hugo Landau wrote:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Hugo Landau <[email-masked]>
Date: Sat, 27 Feb 2016 00:34:50 +0000

> their account key periodically doesn't have to update DNS at the same time.
That's workable. The only issue I can see with this is that an account
URL is a somewhat obscure thing (people might have issues finding it;
though this can of course be rectified by better client design), and
doesn't inherently reveal the account key thumbprint. This means that if
someone is asked to put an account URL in CAA, and they don't have the
corresponding private key to be able to read the account info, they
don't necessarily know what they're endorsing. Then again, in either
case you need to trust the identifier you're given, so it doesn't seem
to make much difference...

> but it might be surprising to some.
I think there's been some mention of the idea that some organizations
might want to use ACME proxies, so this would assist with enforcing that.

> problem.
This is mitigated if DNSSEC is used, in which things become rather
watertight. Something to think about.

> I think if we want to solve (2), we need to add some more
> considered valid for,
As I mentioned in the other thread about CAB BR revision, the separation
between the authorization and issuance process in ACME, although clearly
necessary, creates some issues. I'm not sure that the protocol
accommodates validation processes performed at issuance well; IIRC once
the asynchronous certificate issuance process begins, that means the CA
has already committed to issue the certificate. So you'd have to block
on the issuance call, though that may be fine.

A simpler solution would probably be to use very short authorizations,
since authorizations only need to be valid long enough to complete an
issuance transaction. LE limits to 100 SANs; if you were to assume that
each authorization takes at most, say, two minutes, and are never
made in parallel, even a three hour expiry wouldn't seem unworkable.
I'm not quite clear on why long authorizations are currently used...

> and how, if at all, the domain owner can change
When CAA was drafted I understand there was a lot of concern about how
CAs could use it in anticompetitive ways, or where internally
dysfunctional organizations could have one department use it and
inadvertently prevent another department obtaining certificates from
another supplier. So this is essentially the same concern redux.
A CDN could just as equally configure CAA records for a non-ACME CA,
etc. I would be surprised if any CDN cared so little about irritating
so many customers that it neglected to offer an override for any CAA
records it by default configures.

> right place to implement this?
The CAA RFC envisioned using CAA records to bind to objects more
granular than a particular CA, i.e. an account. It seems like this
is the whole reason parameters were included as an option:

  An issuer MAY choose to specify issuer-parameters that further constrain
  the issue of certificates by that issuer, for example, specifying that
  certificates are to be subject to specific validation polices, billed to
  certain accounts, or issued under specific trust anchors.

I had an idea to also support a 'sufficient' parameter which, when used
with 'acme-ak', would suffice in itself for authorization. This would
obviously require revision of CABF BR, but I was rather more ambivalent
about it because it changed CAA from a necessary to a sufficient step.
This doesn't do that; I think it fits well in the framework of CAA,
as opposed to some other proposals to overload CAA I think I recall
seeing on the list.

Hugo Landau

---

From: Peter Eckersley <[email-masked]>
Date: Fri, 26 Feb 2016 17:21:53 -0800

If we're going to do account key binding, we should try to do it with
cryptographically authenticated protocols. CAA + DNSSEC is one way to get
that, but finding a way to do it over validated HTTPS might ulitimately
be more important because that will be a lot easier for many people to
deploy.

-- 
Peter Eckersley                            [email-masked]
Chief Computer Scientist          Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993

---

From: Hugo Landau <[email-masked]>
Date: Sat, 27 Feb 2016 01:23:43 +0000

This is already the case for HTTP, TLS-SNI and DNS challenges because
they are based on key authorizations which are based on account key
thumbprints. Did you have something else in mind?

Hugo Landau

---

From: Peter Eckersley <[email-masked]>
Date: Fri, 26 Feb 2016 17:30:26 -0800

Oh, yes, sorry, it is a different kind of binding I was thinking of.

What I'm talking about is: once a domain has a cert from an ACME CA (or
any other CA), it should be able to publish a statement saying "only the
following account keys may issue for this domain (or specified
subdomains)".

That effectively removes the non-cryptographic ACME DV attack surface
for that domain.