On Fri, Apr 22, 2016 at 01:23:56PM +0200, Patrick Figel wrote: > 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.
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 > [1] https://cabforum.org/pipermail/public/2016-April/007234.html > > On 22/04/16 13:00, Hugo Landau wrote: > > 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: > >> 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! _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
