Subject: [Acme] draft-ietf-acme-acme-02 authorization

From: Benjamin Hof <[email-masked]>
Date: Thu, 21 Apr 2016 23:24:54 +0200

Hi,

Reading the ACME 02 draft, I have a concern regarding the identifier
authorization life time.

Given a compromised TLS server, the attacker can solve an ACME challenge
and be authorized for the hosts's name.  This authorization can then be
used to obtain valid certificates, even after the intrusion has been
stopped, for as long as the authorization is valid (ten months in
boulder).

This risk comes in addition to common DV exposure and is present for
(almost) any TLS server, not only the ones using ACME.

If the above holds, it would appear beneficial if the authorization was
valid only briefly:  as long as it takes to obtain the desired
certificates.

Is there a reason to allow the long life times?

Thanks!

---

From: Hugo Landau <[email-masked]>
Date: Fri, 22 Apr 2016 12:00:26 +0100

Indeed. I also don't see the need for long authorization lifespans.
Removing autorenewal would complement this well, and simplify the
protocol.

Hugo Landau

On Thu, Apr 21, 2016 at 11:24:54PM +0200, Benjamin Hof wrote:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Patrick Figel <[email-masked]>
Date: Fri, 22 Apr 2016 13:23:56 +0200

It's worth pointing out that the latest draft of the domain validation
ballot[1] written by the CA/B Forum Validation WG set the authorization
lifetime at 39 months:

> Completed confirmations of Applicant authority may be valid for the
> issuance of multiple certificates over time.  In all cases, the
> confirmation must have been initiated no more than 39 months prior to
> certificate issuance.

This begs the question of whether significantly reducing the
authorization lifetime in ACME will result in any real-world security
improvement, given that non-ACME CAs could continue to operate with
lifetimes of up to 39 months.

Boulder's current choice of 10 months is probably a concession to the
fact that some environments are still having a hard time when it comes
to automating the challenges described in ACME. With the current
lifetime of 10 months and a certificate lifetime of 3 months, even a
challenge solved manually will get you certificate coverage for up to a
year, which is comparable to traditional CAs.

[1] https://cabforum.org/pipermail/public/2016-April/007234.html

---

From: Ron <[email-masked]>
Date: Tue, 26 Apr 2016 06:24:36 +0930

> year, which is comparable to traditional CAs.

I think this longer lifetime for authz is actually desirable even beyond
the "some people still have trouble crafting automation" problem.

Requesting and proving authorisation should be an operation that
requires more (and separate) privilege to simply extending the lifetime
of a certificate on the device using it.

My doorbell shouldn't be able to authorise domains for me, but it is
quite reasonable for it to keep its own cert renewed by me giving it
a URL it can GET them from when needed.

Likewise having a single 'admin' server which can (and due to short
lifetimes *must*) perform unattended authz and have unattended access
to *every* machine using a cert to deploy them would seem like
mandating an Achilles Heel at every site using this.

It doesn't seem unreasonable to me to have to retrieve and use an
attended secure token once a year to renew authz, while leaving
more frequent cert renewal as an unattended automatic process.

Separately to that though, I agree a shorter lifetime on authz still
wouldn't actually fix the stated problem.  It seems what we'd really
want for that is the ability to query for all current authorisations
and to be able to revoke them even if you aren't in possession of
the account key that obtained them (but are in possession of the
key which most recently performed authz).

That way when you regain possession of your compromised system(s)
you have a kill switch that can assert sole possession again.

There is a related issue this touches on which I've been wondering
about for a while.  Which is whether there should be a shorter
expiry time for "unused" resources requested from the ACME server.

For example, Boulder currently allows 500 registrations per IP per
3 hours.  So armed with a modest botnet, I could flood it with
something on the order of billions of registrations per hour.
If I have a botnet of IPv6 devices with a /48 or /64, the numbers
start to look, let's go with 'challenging' ...

So I wonder if we shouldn't give some guidance along the lines of
"an unused registration may be purged after an hour" - to give
the ACME server a leak in the bucket that it can manage with the
rate limits it chooses.

That shouldn't cause any major problem for legitimate users, if
they dawdle too long and find the reg discarded, they can just
register the key again.

If we're going to have short expiry certificates, being able to
take down an ACME server like that at its back-end infrastructure
could have significant consequences, leaving some people to wonder
how wise it was to enable HSTS for their site and other only able
to deliver unprotected content ...

So this might be worth some thought.

  Ron

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 25 Apr 2016 15:34:13 -0700

> It seems what we'd really want for that is the ability to query for
all current authorisations and to be able to revoke them even if you
aren't in possession of the account key that obtained them (but are in
possession of the key which most recently performed authz).

Another way to achieve this: We could specify that getting a new
authorization for a domain invalidates all previous authorizations for
that domain. That way, if your account key is compromised, you create a
new key and re-authorize all the domains you previously had. This has
the advantage of not requiring any new operations.

---

From: Ron <[email-masked]>
Date: Tue, 26 Apr 2016 09:33:43 +0930

> the advantage of not requiring any new operations.

I thought I recalled somebody making a case for why having multiple keys
authorised was useful to them, but yes, this is simpler and would work
for me.  It would 'simplify' the key roll-over problem too :)  Since
that would then just become this on a "last key to authz wins" basis.

Which seems about right, whoever controls the name (whether they gained
it through legitimate transfer, regained it after some compromise, or
otherwise) can obtain DV certs though ACME or traditional CA methods.

That would just leave us wanting a way to also revoke certs that might
have been issued to an illegitimate key.  But given the lag that OCSP
has, it might be reasonable to just auto-kill those too, since with
reasonable automation even a 'normal' key roll-over can probably get
new certs deployed before OCSP starts flagging old ones as revoked.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 25 Apr 2016 17:48:34 -0700

> new certs deployed before OCSP starts flagging old ones as revoked. 
I don't think authorizing under a new account key should revoke old
certs. I think in general we want revocation to be an intentional
action, or we risk people accidentally taking their own site down.

---

From: Randy Bush <[email-masked]>
Date: Tue, 26 Apr 2016 10:03:13 +0900

> action, or we risk people accidentally taking their own site down.

this is an old problem.  from loss of private keys (yes, one is inclined
to mis-cite darwin) to people creating bogus pgp credentials with my
email address.

i am not aware of a simple reliable in-band solution.  the examples i
know rely on out of band proof of identity.  oob revocation
authentication usually has scaling issues.

randy

---

From: Ron <[email-masked]>
Date: Tue, 26 Apr 2016 11:54:52 +0930

> authentication usually has scaling issues.

I think the problem in ACME's scope is much smaller.

How you get back control of 'lost' authority for completing a challenge
(ie. exclusive control over your server/DNS etc.) is separate to ACME.

We just need a way to inform the ACME CA once you do that you are now
the authorised authority, and give you the ability to revoke anything
that was granted or issued under any other prior authority.

Automatically cancelling all other authz seems simple enough.  I don't
mind having to manually revoke certs in that case, but I floated doing
that automatically as well because the manual option means adding things
that we don't have yet too.

In theory the reg object returns "authorizations" and "certificates"
(boulder doesn't implement that yet), but -02 says that's only for
"certificates issued for this account" ...  where what we'd need in
this case is certs issued for names under any account (and the ability
for a different account key to revoke them, since you won't have either
the original account key or the original cert key).

I guess the other trick with auto-killing authz, is that the imposter
might have authorised names which are ostensibly under my control,
but which I don't normally have registered with the ACME CA.

i.e., I have my.org and foo.my.org authorised.  After a break-in,
someone gets authz for my.org, foo.my.org, bar.my.org.  If I recover
with my original configuration, bar.my.org wouldn't get auto-killed
since I won't (know to) challenge for it ...

In some ways, that's probably not a lot different from them registering
things I don't know about with a different CA that I don't know about,
but if I have CAA in use, it would be nice to be able to query for all
extant authz for *.my.org with that CA to be sure I can do what is
needed to reclaim them all again.