Feedback on extending SC-088 to include a persistent method for IP Address validation

[Gurleen Grewal]

Hi everyone,

Motivated by (1) the proposed 3.2.2.4.22 included in draft SC-088, (2) Henry Birge-Lee’s recent presentation on risk introduced by ‘crossover’ validation methods, and (3) Chrome’s proposal to sunset those methods - Google Trust Services has drafted a complementary ‘persistent’ IP address validation method for the group’s consideration.

The method is closely modeled after the proposed 3.2.2.4.22, and is intended to offer parity across domain and IP address validation methods in the TLS BRs.

While certificates for IP addresses constitute a small portion of the WebPKI, they are fundamental to the secure operation of critical internet infrastructure. Notable examples include:

• Emergency Access Infrastructure: SSH front-ends, designed for network recovery during major outages (such as the incident affecting Facebook), depend on IP certificates for secure, direct access when domain resolution might be unavailable.

• DNS-over-HTTPS (DoH) services: Systems like 8.8.8.8 (Google Public DNS), 1.1.1.1 (Cloudflare), and 9.9.9.9 (Quad9) rely on IP certificates to establish secure, authenticated channels.

If ultimately 3.2.2.5.3 is sunset due to security concerns, the ecosystem would be without any means to validate IP address control using DNS-based challenges. The remaining HTTP-based methods necessitate running web services on ports 80 or 443, which is sometimes not feasible or desirable for some systems.

Request for feedback: 

1. Do members have concerns about this proposed method (e.g., security / threat model, usability, etc.)?

2. Do members have concern with including it in the scope of SC-088? Or, should it instead be deferred for a later proposal (like Chrome’s, or a dedicated ballot). Combining it with SC-088 makes sense given the subject, but we’d like to ensure members are comfortable with doing so before possibly slowing SC-088’s progress.

Any other feedback is welcome.

Thank you,

Gurleen Grewal, on behalf of Google Trust Services

[Aaron Gable]

At this time, I do not have a strong opinion on whether validation via DNS records at .arpa names is a good idea. Setting that question aside, my first gut reaction is that I would prefer that the proposed 3.2.2.5.8 be phrased more similarly to the existing 3.2.2.5.3 "Reverse Address Lookup". In other words, it should define how to convert an IP address into a .arpa DNS name (with reference to RFCs 1035 and 3596), and then simply defer the rest of the description to Section 3.2.2.4.22. This prevents the need for duplicated text.

Aaron

--
You received this message because you are subscribed to the Google Groups "Validation Subcommittee (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to validation+...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/CAHidiLEM7ht3S1pyTH7D3mg2Vr3xuw8UF2Cx2o4S47CocRvvUQ%40mail.gmail.com.

[Gurleen Grewal]

Hi Aaron,

Great suggestion. I agree that structuring 3.2.2.5.8 similarly to 3.2.2.5.3 to avoid duplication is much better. Repetitive text in the BRs definitely makes them harder to maintain and read.

I've updated the pull request to reflect this change: it now defines the .arpa name construction and defers to Section 3.2.2.4.22 for the DNS TXT record verification details.

I eagerly await the time when you've formed a strong opinion on whether validation via DNS records at .arpa names is a good idea.

-Gurleen

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/CAEmnErfD9GNe6RQgq4vXA%3DfuUjXWP-6BcUKdJX9HuvkxJfgSuw%40mail.gmail.com.

[Aaron Gable]

Thanks, I like this version of the proposed validation method much better.

Here's my concern about DNS-based validation of IP addresses. This is blatantly a slippery-slope argument, and I'm not claiming it's a strong argument. It may very well be that the solution here is to move forward with your proposal and also move forward with something that assuages my concerns.

The slippery slope goes like this:

1) We enshrine dns-based validation of IP addresses via the .arpa namespace.

2) (a year passes) Well, if we're doing dns-based validation, then we should be checking for CAA records in the .arpa namespace, too.

3) (two years pass) Wait, why do these other IP address validation methods not require CAA checks? That's a weird loophole. We should do .arpa-based CAA checks for all IP address validation, regardless of validation method.

And on the one hand, doing CAA checks for IP addresses sounds great! Why shouldn't IP addresses have the same kinds of protections that CAA records can lend to DNS names?

But on the other hand, doing CAA checks for an IPv6 address in the .ip6.arpa dns namespace requires thirty-two DNS lookups to implement correct tree-climbing. With five remote MPIC perspectives (as required in 2026), that's multiplied to 192 queries. Let's Encrypt frequently experiences significantly fewer CAA lookups -- even when spread out over a reasonable time period -- resulting in authoritative nameservers blocking our perspectives, or worse, falling over entirely.

I think that tackling .arpa-based CAA checking is a conversation that this proposal will inevitably lead to, so I'm just speedrunning things and starting that conversation now.

Aaron

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/CAHidiLHyrRZssG75TxZZAphLNPbtujC31A5n-QwfXK-cSjXCWw%40mail.gmail.com.

[Corey Bonnell]

Hi Gurleen,

Thank for you circulating this proposal. I think this proposal is useful for explicitly defining a DNS-based IP address validation method. Since this idea is new (although it’s an extension of the method in SC-88), my personal (non-chair) opinion is that SC-88 should proceed as-is and this IP address validation method can be proposed in its own ballot.

 

I believe going this route enables more focused conversation on this specific method. It also helps the group with creating smaller, more focused ballots that are easier to understand.

 

Thanks,

Corey

 

From: 'Gurleen Grewal' via Validation Subcommittee (CA/B Forum) <valid...@groups.cabforum.org>
Sent: Friday, August 22, 2025 12:07 PM
To: valid...@groups.cabforum.org
Subject: [cabf_validation] Feedback on extending SC-088 to include a persistent method for IP Address validation

 

Hi everyone,

 

Motivated by (1) the proposed 3.2.2.4.22 included in draft SC-088, (2) Henry Birge-Lee’s recent presentation on risk introduced by ‘crossover’ validation methods, and (3) Chrome’s proposal to sunset those methods - Google Trust Services has drafted a complementary ‘persistent’ IP address validation method for the group’s consideration.

 

The method is closely modeled after the proposed 3.2.2.4.22, and is intended to offer parity across domain and IP address validation methods in the TLS BRs.

 

While certificates for IP addresses constitute a small portion of the WebPKI, they are fundamental to the secure operation of critical internet infrastructure. Notable examples include:

 

• Emergency Access Infrastructure: SSH front-ends, designed for network recovery during major outages (such as the incident affecting Facebook), depend on IP certificates for secure, direct access when domain resolution might be unavailable.

 

• DNS-over-HTTPS (DoH) services: Systems like 8.8.8.8 (Google Public DNS), 1.1.1.1 (Cloudflare), and 9.9.9.9 (Quad9) rely on IP certificates to establish secure, authenticated channels.

 

If ultimately 3.2.2.5.3 is sunset due to security concerns, the ecosystem would be without any means to validate IP address control using DNS-based challenges. The remaining HTTP-based methods necessitate running web services on ports 80 or 443, which is sometimes not feasible or desirable for some systems.

 

Request for feedback: 

 

1. Do members have concerns about this proposed method (e.g., security / threat model, usability, etc.)?

 

2.     Do members have concern with including it in the scope of SC-088? Or, should it instead be deferred for a later proposal (like Chrome’s, or a dedicated ballot). Combining it with SC-088 makes sense given the subject, but we’d like to ensure members are comfortable with doing so before possibly slowing SC-088’s progress.

 

Any other feedback is welcome.

 

Thank you,

Gurleen Grewal, on behalf of Google Trust Services

 

--

[Martijn Katerbarg]

>Since this idea is new (although it’s an extension of the method in SC-88), my personal (non-chair) opinion is that SC-88 should proceed as-is and this IP address validation method can be proposed in its own ballot.

 

+1. The IP address section is already separate of the Domain section, which means these would by default become two different items. 

On top of that, SC-88 has already had a long history, seems to be drawing towards a conclusion. Essentially breaking this open again to add the IP discussion, doesn’t seem worth it at this stage.

Regards,

Martijn

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/DS0PR14MB62168F0CAE5CFAEFA3EAF984923DA%40DS0PR14MB6216.namprd14.prod.outlook.com.

[Peter Thomassen]

Hi Aaron,

On 8/22/25 20:10, 'Aaron Gable' via Validation Subcommittee (CA/B Forum) wrote:
> But on the other hand, doing CAA checks for an IPv6 address in the .ip6.arpa dns namespace requires /thirty-two/ DNS lookups to implement correct tree-climbing.

This is not how DNS resolution works. Only one query is required per delegation. You can check using `dig +trace` or at https://simpledns.plus/lookup-dg.

For IPv6 reverse DNS names, that's typically around 4-7 queries, which is 1-2 times (not 14 times) more expensive than looking up a typical hostname.

Note also that referrals from the root and second level will usually be cached (just like for hostnames).

(Of course, this doesn't work if referral responses are being tampered with. However, when assuming an active attacker, no extra queries will provide protection. Protection against that is provided by DNSSEC, which doubles the number of queries because you have to ask for the validation key when following a delegation. However, this is not particular to reverse DNS names, so does not change the factor derived above.)

Best,
Peter

[Aaron Gable]

Hi Peter,

I'd like to better understand your point, because it doesn't quite make sense to me. The CAA RFC (8659) specifically defines the algorithm for locating the relevant CAA record:

> Given a request for a specific FQDN X or a request for a Wildcard

> Domain Name *.X, the Relevant RRset RelevantCAASet(X) is determined

> as follows (in pseudocode):
> 
> Let CAA(X) be the RRset returned by performing a CAA record query

> for the FQDN X, according to the lookup algorithm specified in

> Section 4.3.2 of [RFC1034] (in particular, chasing aliases). Let

> Parent(X) be the FQDN produced by removing the leftmost label of

> X.

> 
>    RelevantCAASet(domain):
>      while domain is not ".":
>        if CAA(domain) is not Empty:
>          return CAA(domain)
>        domain = Parent(domain)
>      return Empty 

This algorithm does not care about DNS delegations, it cares about DNS *labels*. The algorithm describes performing this whole sequence of lookups, until encountering the first real CAA record (or continuing all the way to the end if none exist):

- dig -t CAA 9.5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.4.6.4.4.0.c.1.f.1.0.0.6.2.ip6.arpa

- dig -t CAA 5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.4.6.4.4.0.c.1.f.1.0.0.6.2.ip6.arpa

- dig -t CAA 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.4.6.4.4.0.c.1.f.1.0.0.6.2.ip6.arpa

- etc

- dig -t CAA 2.ip6.arpa

- dig -t CAA ip6.arpa

- dig -t CAA arpa

Are you saying that the DNS returns some metadata such that a query for CAA in 9.5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.4.6.4.4.0.c.1.f.1.0.0.6.2.ip6.arpa will definitively tell me that no other CAA records exist on any subdomain up to some specific parent domain, and that therefore I can skip doing some of those queries? I'm not aware of that being the case, but would love to be proven wrong.

Thanks,

Aaron

--
You received this message because you are subscribed to the Google Groups "Validation Subcommittee (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to validation+...@groups.cabforum.org.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/2ca71376-96e1-4e91-aa01-195a7452aa28%40thomassen.io.

[Peter Thomassen]

Hi Aaron,

On 8/29/25 00:42, 'Aaron Gable' via Validation Subcommittee (CA/B Forum) wrote:
> I'd like to better understand your point, because it doesn't quite make sense to me. The CAA RFC (8659) <https://datatracker.ietf.org/doc/html/rfc8659#name-relevant-resource-record-se> specifically defines the algorithm for locating the relevant CAA record:
>
[...]

>
> This algorithm does not care about DNS delegations, it cares about DNS *labels*.

Indeed, I did not consider that the CAA lookup method differs from a usual DNS lookup. Apologies, I was talking about the latter when I should have realized you were talking about the former.

> Are you saying that the DNS returns some metadata such that a query for CAA in 9.5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.4.6.4.4.0.c.1.f.1.0.0.6.2.ip6.arpa will definitively tell me that no other CAA records exist on any subdomain up to some specific parent domain, and that therefore I can skip doing some of those queries?

No, you are correct. Indeed, this sort of lookup does not seem suitable for checking the CAA policy on IPv6 reverse names.

This lookup logic stems from the fact that CAA records can live on some higher level in the hierarchy without defining a wildcard record. This is useful because a record defined at, e.g., example.com applies to www.example.com as well.

For IPv6 (and IPv4) reverse DNS names, that does not seem equally useful. It may be sufficient to require a CAA record that is retrieved via a standard DNS lookup at the FQDN reverse name (as I had mistakenly assumed in my previous message). A reverse zone owner can then easily cover their case by setting the CAA record directly at the FQDN, or using a wildcard that applies to that FQDN (restricted to the same zone, though). The subdomain situation that's useful for hostnames does not seem to apply here.

These are just some ideas, and I'm aware they would likely require an RFC. When the time comes to think about CAA validation for reverse DNS names, it may be worthwhile to think whether the lookup method can be adapted to make the method suitable.

In any case, thank you for the correction!

Best,
Peter