Trust and domain ownership validation


#1

This is an attempt to continue a side discussion from another thread that had split off the main topic over here:

All sensitive ACME messages are already signed with the account key. Encrypting the token doesn’t add any additional proof other than your the same person who submitted the original order. But the attacker doesn’t need to impersonate your account. It can create it’s own brand new account and submit a new order. The whole point is that controlling the DNS namespace of the domain is all you need to prove you own it.

The proposed extensions to the CAA records that would allow you to pin a specific account key to a domain almost get you there and are probably the closest thing to what you’re looking for. I think it would solve the trust problems with the hypothetical CNAME-only provider we were originally talking about. Even if a malicious CNAME provider captured the account thumbprint used in previous TXT records, it couldn’t create a new order with the existing account because it doesn’t have the account key. It also couldn’t create an order with a new account because it wouldn’t match the CAA record.

But a malicious DNS provider that manages the whole zone could just as easily remove the CAA record long enough to generate an order and a cert before putting it back the way it was.


Service that automatically provisions CNAME redirection for DNS challenges
#2

I think this topic is also of interest to @jsha.


#3

This is definitely key to moving forward.
Is there a timetable for this?


#4

Brief update: We’re blocked on deploying this to production waiting on a CABF ballot to be adopted giving us permission to reference RFC 6844 errata for the original ambiguous grammar ahead of a longer term switch to RFC 6844-bis.

But maybe there is an update?


#5

Not much update on the ACME-CAA account key issue. The current route that looks most likely: wait for RFC6844bis to be finalized (it’s close), then get that adopted at CABF.