Proposal to Implement ACME "dns-account-01" Challenge in Boulder

sheurich commented 8 months ago

Description:

I propose integrating the "dns-account-01" challenge into Boulder. This challenge introduces a novel method for domain control validation within the ACME protocol.

Background:

The "dns-account-01" challenge, in its current Internet Draft form, introduces an additional approach for domain control validation. It uses a DNS resource linked to the ACME Account ID, offering enhanced flexibility and security in domain validation processes.

Proposal:

Integration of "dns-account-01" Challenge: Implement the "dns-account-01" challenge in Boulder following the specifications and implementation details outlined in PR #25, and adapt to any updates as the draft evolves.
Commitment to Contribute: I am prepared to submit a PR for this challenge's implementation in Boulder, adhering to the project's contribution guidelines and best practices.

Rationale:

Enhanced Domain Validation: The "dns-account-01" challenge provides a more versatile and secure method for domain validation, enhancing Boulder's capabilities.

Request for Comments:

I invite the Boulder community to discuss this proposal. Your feedback on the implementation, potential challenges, and the overall impact on Boulder's functionality is highly appreciated. I look forward to collaborating on this feature.

aaomidi commented 8 months ago

I'm one of the authors of that draft, I'll also commit to helping with this implementation if need be!

Thank you so much for this, @sheurich

aarongable commented 8 months ago

We'd be happy to accept contributions implementing DNS-ACCOUNT-01!

A few notes:

Please implement DNS-ACCOUNT-01 in pebble first, to help maintain parity between the two ACME implementations and to ensure that clients implementing DNS-ACCOUNT-01 have a testbed to test against.
As always, please break large changes down into easily-reviewable sections, preferably as separate PRs, but failing that as well-structured commits within a single PR. I honestly don't have a good instinct for how large this change is going to be, so it may fit in a single PR just fine, but keep it in mind.
Just as a heads-up: we do automatic round-robin assignment of reviewers to PRs. Your first assigned reviewer should respond to the PR in about one business day, and other reviewers should take a look shortly after that. If the change is broken into multiple PRs, they'll likely be assigned to different people for their first round of review.

sheurich commented 8 months ago

Great, thanks! I created https://github.com/letsencrypt/pebble/issues/425 for the Pebble work.

sheurich commented 6 months ago

In contrast to the Pebble implementation, the Boulder work has the additional complication of component separation. The method used in Pebble's wfe.updateChallenge:

        // Reconstruct account URL for use in scoped validation methods
        acctURL := wfe.relativeEndpoint(request, fmt.Sprintf("%s%s", acctPath, existingAcct.ID))

        // Submit a validation job to the VA, this will be processed asynchronously
        wfe.va.ValidateChallenge(ident, existingChal, existingAcct, acctURL, wildcard)

could be implemented in Boulder but this requires a change in the RA/VA gRPC definition for PerformValidationRequest (e.g. an additional member of AuthzMeta).

One alternative could be statically defining account URL prefixes in configuration cf. https://github.com/orangepizza/boulder/blob/703182fae06ccf8e876a9c6bdc71b5e4186d630d/va/dns.go#L132-L133.

The protobuf change would be small and additive, while the configuration approach is a more localized change. How does this comparison align with the overall strategy in Boulder development?

aarongable commented 6 months ago

The Boulder VA is already configured with a set of accountURIPrefixes. The IsCaaValid gRPC method combines those prefixes with an accountURIID to check that CAA "accountURI" parameters are correct.

The AuthzMeta protobuf already contains the account's regID, which can be used in exactly the same way. Combining that regID with the accountURIPrefixes should give the full account URI, which can then be fingerprinted per the IETF draft.

edit: gah sorry, I now see that you already proposed this configuration-based approach in your comment above. Yes, I think that is the correct path forward :)

letsencrypt / boulder