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.
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.
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.
I noticed that RFC8657 (CAA Account URI + ACME Validation Method) was published yesterday, and it references the newer RFC8659 CAA standard (formerly RFC6844bis?).
I guess that means the RC6844 5452 errata never made it.
This erratum did make it, in the sense that its status was "held for document update," and the relevant changes made it into the updated document, RFC 8659. However, ACME-CAA still went ahead and used non-hyphenated names because it was simpler.
As BR specifically call RFC 6844 for definition of CAA, does it follow updated RFC?
CAA: From RFC 6844 (http:tools.ietf.org/html/rfc6844): “The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the Certification Authorities (CAs) authorized to issue certificates for that domain. Publication of CAA Resource Records allows a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue.”
Not automatically – it will take a CA/B Forum ballot to authorize use of the new RFC. (Not to mention CAs updating their software.) It won’t happen overnight.
Note that CA/BF BR update ballots have an IP waiting period (where members have to announce if they have patent claims that they think read on the methods or procedures adopted in the ballot), so this change won't take effect right away. I forgot how long that is, but I think it's a couple of weeks.
A new version of the Baseline Requirements was released less than one month ago (1.7.3). According to the new version SC35 is now effective as of 19-Oct-2020.
Is enabling RFC 8657 in production on the roadmap? and any chance we could get a ETA?
Is there an update on the ETA for RFC 8657? Is there an alternative way to prevent someone from obtaining a certificate using only an http challenge for 'my' domain?
There was a post last month with a nebulous "soon" but with other priorities happening first. With no firm date yet, and with them working on the new IdenTrust cert chain stuff now, I'm guessing there's still a good amount of waiting left to go.
There is a "workaround" of sorts suggested in that thread, where (assuming you can automate the DNS updates easily) you set your CAA to not allow any issuance except for the times you're running your "authorized" renewal process during which you set it to allow Let's Encrypt. That's probably the best you can do in the meantime.
If you want to stave off the potential of unauthorized issuances even more, you might want to stagger your renewals from their default [predictable] 60 day cycles.
And always check CT logs after you have modified the CAA records to ensure that all new issuances were expected.
[and check CT logs periodically - like weekly - even during times when the CAA records weren't modified]
