Dns-persist-01 wildcard authorisation depth

Issuance Tech
1

Possibly one for @aarongable ...

I know dns-persist-01 isn't even in staging yet ... I'm thinking about how I might use it with IP address certs as I'm lucky enough to have an ISP that not only gives me static IPs but also delegates the appropriate bits in-addr.arpa and ip6.arpa.

I'm trying to get my head around dns-persist-01's policy=wildcard handling and how far up (or down) the tree it works.

My reading of it is that if you've set up a record at _validation-persist.example.com that includes "policy=wildcard", that is meant to authorise requests for example.com, *.example.org, www.example.org and so on. According to section 5.1 of the draft though, it would also authorise a name such as server.dept.example.org, which wouldn't be covered by a certificate for *.example.org.

However the draft only seems to refer to checking for a _v-p record at the authorisation domain name, and not at any higher level, so I don't immediately see how a wildcard authorisation would ever be checked.

If I'm asking for a certificate for server.dept.example.org, is the CA going to start by looking for _validation-persist.server.dept.example.org, then if it doesn't find that, will it remove leading components of the requested domain name in the same way as when looking for CAA records?

If so, at what point does it stop? Does it go all the way up to (but not including) the PSL domain (so checking _v-p.server.dept.example.org, _v-p.dept.example.org and _v-p.example.org), or does it only check the requested domain and with the first leading component removed (ie _v-p.server.dept.example.org, _v-p.dept.example.org)?

If the intent is to take the first approach, it seems to me that there's some potential nastiness in that an ISP who had 192.0.0.0/16 could then set up a record at _v-p.0.192.in-addr.arpa with policy=wildcard that would then allow them to request certificates for any IP address in that range, unless there was an authorisation record "closer" to the customer's own IP. That being said, I don't think that's exposing any new risks.

Obviously you could put your own record in at the top of your delegation, and that would indicate you wanted to authorise your account and not the ISP's. I suppose then if you wanted to prohibit dns-persist-01 being used you could create a record with a junk issuer-domain-name, eg "no.dnsp01.here; accounturi=null". (If the ISP spoofs NXDOMAIN for TXT records in zones they've delegated to you then you have bigger issues, see above.)

The second approach (limiting the search to the requested domain name and with the first leading component removed) feels more in keeping with the semantics of a wildcard certificate, but one immediately obvious downside is that it would make wildcard dns-persist-01 impractical for IPv6 reverse zones. It would also not be consistent with the search process for CAA records.

When I started writing this I was fairly sure I preferred the idea of limiting how far up the tree you looked, but the more I think about it the more I'm leaning towards allowing a search all the way up to (but not including) the PSL domain.

I hope I've made that clear. Please let me know if any of it doesn't make sense and I'll try to clarify!

Thanks!

1 Like
2

I think the one thing you're missing, that makes this all almost make sense, is the concept of an "Authorization Domain Name" (ADN). The BRs define this as:

Authorization Domain Name : The FQDN used to obtain authorization for a given FQDN to be included in a 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.

That's a big definition, and also a really bad one (we're working on a whole ballot to fix it), but it gets the main idea across: for certain validation methods (of which dns-01 and dns-persist-01 are included), the CA may select any parent domain as the ADN and choose to perform validation at that ADN instead of at the requested FQDN.

This definition exists because it is useful for big CAs and big corporations to be able to negotiate an ADN at which all validation will occur. You want to get certificates for ten thousand doubly-nested subdomains of example.com? Contact CACorp and have your rep put a note on your account saying that all validations should be done at example.com itself, rather than on each individual subdomain. This works great for corporations and CAs that have support staff who can arrange such things.

The problem is that ACME hasn't historically had a mechanism to negotiate an ADN. RFC 8555 says that ACME clients should put the dns-01 record directly at the name they're requesting, so that's what all ACME clients have done, and that's the only place ACME servers have checked. This new method is opening up a new world of possibilities, and the ACME protocol may need to adapt to support it. In fact, I filed a bug about this against the dns-persist-01 Internet Draft over a month ago, but there hasn't been motion on it yet.

All of that is a long way to say you're asking very good questions, and we don't fully know the answer yet :slight_smile:

7 Likes
3

Oh, a few additional notes:

We don't issue certificates for DNS names under the in-addr.arpa range (and IIRC doing so is forbidden by the BRs). We do issue certificates for IP addresses, and the BRs do allow for DNS-based validation of IP addresses via the in-addr.arpa namespace, but then the concept of an Authorization Domain Name doesn't apply. That definition only applies when validation an FQDN, not when validating an IP address, even if you're using an FQDN to perform said validation.

This doesn't work. Just like CAA, dns-persist TXT records are additive. A bad record doesn't block issuance, it just doesn't allow it. As long as there is one record which allows issuance, that's enough. The presence of any other records which would on their own not allow issuance doesn't mitigate the presence of one record which does allow issuance.

4 Likes
4

It's reassuring to know I'm not the only person who's gone "Huh?" even if there were some subtleties that I'd missed :slight_smile: Thank you Aaron!

Oh of course, yes. I'd melded an actual IP address and its representation in in-addr / ip6.arpa rather too strongly in my mind. The ADN concept not applying for IP addresses themselves suggests that (for my planned use case at least) I don't need to worry.

I hadn't appreciated that CAA and _validation-persist were additive -- thank you for clarifying that :slight_smile:

2 Likes
5

I submitted a somewhat related issue to the draft repo about concerns about the additive validation in the case of TLD operators and such.

From a technical standpoint, it seems like there's a lot of room for abuse from high level namespace operators.

5 Likes
6

If that was a random example... Then it's not the best one - as that network overlaps 192.0.2.0/24 which is a TEST NET: ARIN Whois/RDAP - American Registry for Internet Numbers
As such (and as with the IPs in RFC 1918 ranges), no certificates can be issued for that IP range.

5 Likes
7

Funnily enough I did have 192.0.2.0/24 in mind (and was aware that no certs can be issued for that range) ... yes, I should probably have picked something like 131.111.0.0/16 instead :slight_smile:

5 Likes