Seems like a good extension.
> In the rare event of a collision, a new ACME account can be generated. Should that be mentioned in the Security Considerations section? I'm thinking that you could add to the end of your existing S.C. something like "Certification Authorities (CAs) MAY, during ACME account creation, check that the DNS-ACCOUNT-01 prefix is unique in their database ..." Could you expand on this? > This ability is especially useful in the case of wildcard certificates, for > which no other ACME challenge allows issuance today. Why is this method more amenable to wildcards than existing ones? What are the policy implications of this, ex. at the CA/B F level? --- Mike Ounsworth -----Original Message----- From: Acme <acme-boun...@ietf.org> On Behalf Of Antonios Chariton Sent: September 8, 2022 12:08 PM To: IETF ACME <acme@ietf.org>; aaom...@google.com Subject: [EXTERNAL] [Acme] New ACME Challenge Proposal WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. ______________________________________________________________________ Hello everyone, This email serves to propose a new ACME challenge to this working group called DNS-ACCOUNT-01, which is available here: https://urldefense.com/v3/__https://daknob.github.io/draft-todo-chariton-dns-account-01/__;!!FJ-Y8qCqXTj2!Z52HhpPiq1S1WtA1bV_pO2FNJFp5suwJIqrjiAsDYnSQ5qiXTfKsNsIAxY1wau6cCelAm9lNha4tlUcp9hEtNEdc$ and here: https://urldefense.com/v3/__https://daknob.github.io/draft-todo-chariton-dns-account-01/draft.txt__;!!FJ-Y8qCqXTj2!Z52HhpPiq1S1WtA1bV_pO2FNJFp5suwJIqrjiAsDYnSQ5qiXTfKsNsIAxY1wau6cCelAm9lNha4tlUcp9vqzsJve$ (as a TXT). We have already solicited community feedback publicly in Mozilla's Dev Security Policy (MDSP) Mailing List, here: https://urldefense.com/v3/__https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/ICnTV94XyfM__;!!FJ-Y8qCqXTj2!Z52HhpPiq1S1WtA1bV_pO2FNJFp5suwJIqrjiAsDYnSQ5qiXTfKsNsIAxY1wau6cCelAm9lNha4tlUcp9pQl4Hsy$ . DNS-ACCOUNT-01 extends (but does not replace) the DNS-01 challenge in the following way: the DNS label under which the TXT record is created to respond to the challenge is account dependent. This allows a Subscriber to use multiple and separate subdomains to solve ACME challenges for the same domain. In DNS-01, the ACME server checks for DNS records under _acme-challenge. In DNS-ACCOUNT-01, the server will check for DNS records under _acme-challenge_accountUniqueValue, e.g. _acme-challenge_ujmmovf2vn55tgye. The last part is constructed from base32-encoding a part of the SHA-256 hash of the ACME Account URL. This allows each ACME account to use a separate label for the TXT record. We believe that BR Method 3.2.2.4.7 can be used with the proposed challenge for proof of domain control in the Web PKI. The current limitation of the DNS-01 challenge is that since CNAME records are unique per zone, a user would be unable to point the _acme-challenge label to more than one destination, so the following scenario is not supported: _acme-challenge.example.com. IN CNAME automated-dns-01.example.org. _acme-challenge.example.com. IN CNAME automated-dns-02.example.net. If every ACME account has a unique label, then you can easily achieve this: _acme-challenge_ujmmovf2vn55tgye.example.com. IN CNAME automated-dns-01.example.org. _acme-challenge_vfp2fz4sfemzl4vh.example.com. IN CNAME automated-dns-02.example.net. With this new challenge we can allow a domain owner to delegate domain control validation to separate DNS records, that can, in turn, prove domain control and request certificates. We found this to be useful in several scenarios such as the following: Hybrid Deployment Environments Some services may be running in a hybrid environment and require multiple instances to have access to (wildcard) certificates for the same domain name. As they will be using different ACME accounts, a different DNS record can be set up for each environment, without causing issues. Multi-Regional Deployments There are providers that have an infrastructure running in multiple regions and do not want to introduce dependencies across regions. They want to have the ability to issue certificates for the same domain as other regions, without relying on any particular one, to achieve resiliency, etc. Load Balancing Allowing each TLS-terminating endpoint to get its own certificate, without having to share and move private keys around, or adding common API keys for DNS, can be beneficial. Zero-Downtime Migrations If some infrastructure has to be migrated from one system to another, and it has to be done gradually, but the eventual change is a cut-off point, when the DNS records finally change, there is a need for the ability to allow both the old and the new infrastructure to obtain the same certificates, at the same time. This ability is especially useful in the case of wildcard certificates, for which no other ACME challenge allows issuance today. We considered different methods for constructing the accountUniqueValue that gets prepended to _acme-challenge_. One of our considerations was to rely on a CA-specific "special string", similar to the ones used in CAA records. However, this only allows a single delegation per CA, and it would not address all of the above use cases. Another alternative is to rely on the ACME Account Key, however this is not stable long-term and has the ability to change, and relying on its staleness would actually reduce user security. The SHA-256 hash is truncated in the hostname to reduce the DNS record size. As it is not relied on for security, we believe that it provides adequate entropy, without massively increasing the record size. In the rare event of a collision, a new ACME account can be generated. We chose not to relay the requested label in the ACME server message, and instead have the client calculate it independently, for security purposes. It helps prevent cross-protocol attacks that could be introduced in the future, and it also helps protect the ACME client against malicious ACME servers or certificate misissuance. During the feedback phase in MDSP, we received a private comment on a potential issue with RFC 8552 and RFC 8553 due to the label being dynamic and not static, as it is with the DNS-01 challenge. However, RFC 8145 defines the _ta-* label, which is also dynamic, and there's an explicit clarification in the registry, so we do not believe that there will be any issues with IANA. We would like to start a discussion with the Working Group about this proposal and proceed with the next steps. Thanks, Antonis _______________________________________________ Acme mailing list Acme@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!Z52HhpPiq1S1WtA1bV_pO2FNJFp5suwJIqrjiAsDYnSQ5qiXTfKsNsIAxY1wau6cCelAm9lNha4tlUcp9rl1YUgv$ Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
