Use leaf of _acme-challenge

[Saklad5]

_acme-challenge is already reserved for ACME, and that extends to every TXT record under that node. I see no reason not to take advantage with leaf nodes, like so:

_ujmmovf2vn55tgye._acme-challenge.www.example.org 300 IN TXT "LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI"

This approach avoids the need for a new IANA registration, and has the additional benefit of making it easier to delegate authority for all ACME records as another zone.

[daknob]

Hello and thank you for your suggestion!

Although ACME is not limited to Web PKI CAs ("publicly trusted"), we would like to make this challenge compatible with its current rules.

In Section 3.2.2.4.7 of the current version of the CA/B Forum Baseline Requirements (1.8.6), a CA can only accept Random Values (the TXT record value) under at most one label lower than the domain it is validating, that must start with an underscore.

From my interpretation, validating _foo.example.com would allow for issuance of certificates for example.com, but validating _foo._bar.example.com would only allow issuing certificates for _bar.example.com (ignoring other rules).

It is true that the Baseline Requirements can be amended, however we believe that our current design requires no changes, and can therefore be easier to adopt. Moreover, introducing the ability to have an arbitrary amount of prefixed labels in the validated domain can introduce security risks.

Indeed, this current proposal requires a new IANA registration, however we believe that the tradeoffs made are reasonable and overall better support DNS-ACCOUNT-01 for use in the Web PKI.

[Saklad5]

I was not aware of that rule, though a careful reading of the definition of "Authorization Domain Name" will show that it allows multiple labels.

The CA may prune zero or more Domain Labels of the FQDN from left to right until encountering a Base Domain Name and may use any one of the values that were yielded by pruning (including the Base Domain Name itself) for the purpose of domain validation.

I don't think this would ever work without the CA/B Forum's approval, regardless of technicalities. I think it is best to focus on what actually makes the most sense from a technical standpoint, and I feel that means using the tree structure of DNS labels for their intended purpose.

[Saklad5]

Moreover, introducing the ability to have an arbitrary amount of prefixed labels in the validated domain can introduce security risks.

I don't know what you mean by this. This would require an exact quantity of prefixed labels (two).

[daknob]

Thank you for your comments!

The current text, as is, is compatible with the Baseline Requirements, which do not specify an exact label, but any value that begins with an underscore. In fact, the existing DNS-01 challenge is based on this section. The two other main ACME challenges, HTTP-01 and TLS-ALPN-01, had to get amendments (3.2.2.4.19 and 3.2.2.4.20) to be usable in the Web PKI.

As the proposed DNS-ACCOUNT-01 is verifying a TXT record for "an Authorization Domain Name that is
prefixed with a Domain Label that begins with an underscore character", much like DNS-01, it is my assessment that it would work without issues.

If there is something that I am missing in the text, I am happy to have a look. This is my personal understanding, and it may be wrong. From a quick search in the document, DNS-01 does not appear anywhere, nor are there any relevant sections when searching for ACME. It's just HTTP and TLS methods.

Indeed, Section 3.2.2.4.7 mentions that the record can be in an Authorization Domain, whose definition you quote above. This is better clarified in the Note that follows. My understanding is that if the FQDN (the domain that will be included in the certificate) is www.example.com, you can only remove sections and validate that, not add. That means that for a certificate that includes www.example.com, for 1 you'd need to validate either www.example.com or example.com, and for 2 you could validate _*.www.example.com.

If a CA wanted to solve a challenge under _foo._bar.example.com, then I don't think it could ever issue a certificate for example.com without being non-compliant. If it used 1 then it could issue for _foo._bar.example.com and any of its subdomains, and if it used 2 it could also issue for _bar.example.com as well.

Do you agree with the interpretation above? I'm happy to hear any thoughts!

Finally, for your last comment, one could add a "3" to the BRs that would allow up to two labels that both start with a _, but this would require changes.

When we were designing DNS-ACCOUNT-01, we tried to avoid requiring any changes to the Baseline Requirements, and we considered this a good "feature". Not because these changes are impossible to make, but because we would put the new challenge and DNS-01 in the same "bucket". There wouldn't be any differences in terms of compliance with the BRs, and CAs could adopt this more easily.

This doesn't mean that this "feature" has to stay, however I believe there is a cost in losing it, and the gains from doing so would need to outweigh that cost for it to be a good decision / tradeoff.

Thanks,
Antonis

[Saklad5]

My understanding is that if the FQDN (the domain that will be included in the certificate) is www.example.com, you can only remove sections and validate that, not add.

An Authorization Domain Name may be distinct from the domain name it is authorizing, as evidenced by the start of its definition.

The FQDN used to obtain authorization for a given FQDN to be included in a Certificate.

At no point do the Baseline Requirements constrain what the Authorization Domain Name may be. If this standard states that the Authorization Domain Name of the FQDN <www.example.org> is the FQDN <_ujmmovf2vn55tgye._acme-challenge.www.example.org>, that would be allowed. Because of the ability to prune an arbitrary number of labels, that would also allow CAA records to be used as normal.

---

Even if that wasn't the case, this contravenes the intent of underscored and globally scoped domain names to satisfy requirements that are meant to be revised and expanded upon.

IANA has never approved any reservation like what the current design proposes: the sole assignment like it (ta-*) was grandfathered in as part of RFC 8552. The intent of the RFC is that each reservation be reused for nodes under it. This is the "scope" that the registry refers to.

[daknob]

Thanks for your comment! I think that since this is turning out to be a large conversation, it would be perhaps better to have it in the mailing list, so everyone can see it and participate.

This document is part of the ACME Working Group of IETF. The Baseline Requirements are published by the CA/B Forum. Therefore unfortunately we cannot redefine terms or change the rules of the other document. Each document may refer to the other (the BRs mention RFC 8555), but there's no "jurisdiction" that a document has to change the other.

They were created by separate entities for separate reasons. Any change in the BRs would require someone to follow the CA/B Forum process for achieving that. And of course, there's no guarantee of success: if a change is perceived as weakening the security of the Web PKI, for example, it would not be accepted.

If we require a change of the BRs, especially one that allows for broader possibilities of domain validation, we risk it failing, and rendering this proposal less useful. A lot of parties have so far expressed a need for this to be used in the Web PKI, and we'd therefore like to make them compatible. If we break BR compatibility then we risk making this only usable in private PKIs.

As far as the IANA registry is concerned, I don't see why this can't be the second reservation with a wildcard. It is up to the experts of the registry after all, and there may be valid reasons. If the registry can only be used for different types of records, then perhaps this use doesn't have to be registered at all? I am not sure, and I can't comment on this part, so perhaps a conversation in the mailing list can shed more light.

Antonis

[aarongable]

At no point do the Baseline Requirements constrain what the Authorization Domain Name may be.

This is incorrect. The Authorization Domain Name is defined as the FQDN used to obtain authorization, which sounds like a wide-open definition, but there are restrictions on what FQDNs can be used to obtain authorization, and therefore there are restrictions on what FQDNs can be Authorization Domain Names (all following quotes from the definition of Authorization Domain Name in Section 1.6.1 of the BRs):

The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation.

i.e. the Authorization Domain Name may be the FQDN to be included in the Certificate

The CA may prune zero or more Domain Labels of the FQDN from left to right until encountering a Base Domain Name and may use any one of the values that were yielded by pruning (including the Base Domain Name itself) for the purpose of domain validation.

i.e. you can convert the Certificate FQDN into an Authorization Domain Name by pruning labels from left to right.

In other words, you cannot go the other direction: you cannot convert an Authorization Domain Name into a Certificate FQDN by trimming labels from left to right.

Therefore, if the TXT Record is _foo._bar.example.com, then the Authorization Domain Name is _bar.example.com, and you can issue for *._bar_example.com but not for example.com.

[sheurich]

No disagreement with your definitional interpretations @aarongable.

Considering the relevant text of the Baseline Requirements §3.2.2.4.7 DNS Change

Confirming the Applicant's control over the FQDN by confirming the presence of a Random Value or Request Token for either in a DNS CNAME, TXT or CAA record for either 1) an Authorization Domain Name; or 2) an Authorization Domain Name that is prefixed with a Domain Label that begins with an underscore character.

In particular, the proposed validation label

"_" || base32(SHA-256(Account Resource URL)[0:9]) || "._acme-challenge"

matches the BR §3.2.2.4.7 requirement

an Authorization Domain Name that is prefixed with a Domain Label that begins with an underscore character

as it is prefixed with "a Domain Label that begins with an underscore character".

The proposed validation label format seems to align with the criteria for DNS-based validation.

[orangepizza]

I think he means "_something._acme-challenge" prefixes two domain labels {"_something", "_acme-challenge"} , not one
like a wildcard certificate only covers single depth so *.example.com doesn't cover foo.bar.example.com

[aarongable]

Yes, @orangepizza is correct. The issue isn't that "_" || base32(SHA-256(Account Resource URL)[0:9]) || "._acme-challenge.example.com" isn't prefixed with "a domain label that begins with an underscore", the issue is that "._acme-challenge.example.com" isn't an Authorization Domain Name (i.e. it isn't produced by taking the example.com and pruning zero or more labels from the left).

So assume that example.com itself is the Authorization Domain Name. Then BRs only allow the Authorization Domain Name to be prefixed by a domain label, not two, so "_" || base32(SHA-256(Account Resource URL)[0:9]) || "._acme-challenge.example.com" is non-compliant.

The authors of this draft are well aware of this issue and, last I heard, intend to propose a change to the baseline requirements to allow this double-prefixing.

[sheurich]

The authors of this draft are well aware of this issue and, last I heard, intend to propose a change to the baseline requirements to allow this double-prefixing.

Great! In that case, is LE comfortable proceeding with this draft version?

[aarongable]

I think it is best that whatever is implemented (both in Pebble and in Boulder) be whatever is represented by the latest official draft at https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account-challenge/. For better or worse, that's currently the single-prefix "_acme_challenge_<base64(url)>.authorization.domain.name". I've been told offline that the authors plan to change the draft to use the two-prefix mechanism; I hope that they update the official working group document to reflect that (or make it clear that they do not intend to do so and I am mistaken) soon.

[aaomidi]

We're currently working on making those changes, and I hope to have them ready by the EoW. Let's wait on that before we proceed further here!

Please note, that we ware aware the changes we're working on will break compatibility with the BRs. This is on purpose as the IETF process shouldn't necessarily be bogged down by the BR & CAB Forum process. Alongside this, we will be looking into making the necessary changes in the BRs as well.

[wthayer]

@aaomidi I represent Fastly at the CAB Forum and am extremely eager to begin using dns-account-01 because it solves a significant barrier to adopting ACME. Would it be okay for me to open discussions on this with the Validation Subcommittee this week, understanding that the draft will be updated very soon? I am happy to volunteer to shepherd a ballot through the CAB Forum.

[orangepizza]

if a CAB ballot is made, would it better add a new challenge method pointing this draft or amend 3.2.2.4.7 to allow this kind of multi label structure?

[wthayer]

@orangepizza I do think it is probably safer to create a new specific method, but I also think that the CABF would strongly prefer to point to an RFC, so going that route could really block the use of this mechanism. My goal is to find a way to make this usable prior to RFC publication.

[orangepizza]

old version of CAB TLS BR before 2.x (sc62) used https://tools.ietf.org/html/draft-ietf-acme-ip-04#section-4 as pointer to acme challenges for IP addresses, so I think it's better to make a specific method. (possibly they'll make _pki-validation subdomain version too?

[orangepizza]

BTW because I didn't enter those discussion until few days ago: what was the problem of old single label challenge subdomains?

[aaomidi]

what was the problem of old single label challenge subdomains?

Which ones?

[orangepizza]

Currently in doc _hash_acme-challenge.example.cpm

[aaomidi]

I'll try to just re-iterate this if it comes up in the mailing list again:

There were a couple of things going on at the same time that led us to change course a bit.

1. It really felt like we're designing around BR constraints, instead of treating this as "what would we do in the ideal situation". Given that we also received the same feedback at IETF, we decided to go back to the drawing board for it.

2. The folks from dnsops have been also working on a great proposal for best practices on DNS validation (not only ACME related, but overall DNS validation related): https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/

3. Given the primary use case of dns-account-01 is to establish CNAME based validation delegation, I've always felt like there should be a bit more granular controls over this delegation. Expand draft to use dns-scoping & create DNS-01 #34 expands on that, and actually introduces dns-02 with the same scoping methodology too!