Require Multi-Perspective Domain Validation (v1)

[ryancdickson]

Content derived from:

https://docs.google.com/document/d/1Vg8qwH_slheGofmj-lKt0P-bMNezlML3n89g8dSVSGo/edit#

Opening PR to help facilitate continued discussion.

[birgelee]

Hi Ryan and all,

Our team at Princeton looked over the GitHub diff and we think that overall the draft is quite solid and provides a substantial and measurable security improvement to the PKI. We had a couple of clarification changes that we think would improve that draft that we feel largely do not change the intent of the traft. Below I have listed them:

Change line 1047 "...CAs MAY immediately retry using the same validation method or an alternative method..." to "...CAs MAY immediately retry Multi-Perspective Domain Validation using the same validation method or an alternative method..."

We recommend this change as "CAs MAY immediately retry" does not specify the type of validation. It can be interpreted in two ways (1) Retry Multi-Perspective Domain Validation (2) Retry the domain validation process from Network Perspectives that disagree with the Primary Domain Validation Determination. There are stronger security grounds for approach 1) (which is how I interpreted the language when it was proposed in the google doc), and we feel that adding this clarification would remove any confusion.

In the “Table: # of Network Perspectives and Quorum Requirements,” clarify that line 4 only applies when N >= 6. Based on our work team calls, this is my understanding of this table (which lines up with the results from our most recent paper). We think the way it is written now, someone could potentially interpret it override lines 1 and 2 (e.g., with a value of N = 3), and this clarification would make it more clear.

Add “Validations using this method MUST implement Multi-Perspective Domain Validation as specified in Section 3.2.2.9.” to methods in “3.2.2.5 Authentication for an IP Address” that mirror 3.2.2.4 methods.

Reviewing the draft we noticed that while all relevant methods in 3.2.2.4 (validation of domains) contained a reference to 3.2.2.9 requiring multi-perspective validation, there were several methods in 3.2.2.5 (validation of IP addresses) that closely mirrored methods in 3.2.2.4 but did not have this same reference. While our primary concern is the validation of domains, we feel it is important to secure the validation of IP addresses as well particularly since section “3.2.2.4.8 IP Address” states that an applicant can validate control of a domain by validating control of an IP address (via 3.2.2.5) that is returned from an A or AAAA lookup for a domain. While 3.2.2.4.8 points to 3.2.2.9 which says that the lookup for the domain’s A or AAAA must be done from multiple perspectives, there are no references to multi-perspective validation in 3.2.2.5. Our concern is that this presents a loophole where an adversary can launch a BGP hijack against a domain’s A record and then approach a CA for IP address validation for that address. Because 3.2.2.5 contains no reference to 3.2.2.9, this validation does not need to be performed from multiple perspectives potentially allowing the adversary to fool the CA. Given this IP address validation, the adversary can then approach the same CA requesting a certificate for the victim’s domain and request validation method 3.2.2.4.8. Under these circumstances the CA could use the adversary’s existing validation of IP address control and then perform a multi-perspective lookup for the victim domain and find that the IP address is indeed the true A record of the victim’s domain. In this manner, the adversary has now bypassed multi-perspective validation on communication with the domain’s A record.

We recommend including the text “Validations using this method MUST implement Multi-Perspective Domain Validation as specified in Section 3.2.2.9.” in the following sections:
3.2.2.5.1 Agreed-Upon Change to Website
3.2.2.5.3 Reverse Address Lookup
3.2.2.5.6 ACME “http-01” method for IP Addresses
3.2.2.5.7 ACME “tls-alpn-01” method for IP Addresses

And the following lines be added to “Tabe: Defining Corroborating Domain Validation Evidence”

---

Agreed-Upon Change to Website (defined in 3.2.2.5.1):

This method involves observing changes to website content.

“Corroborate” means the corresponding challenge information (e.g., Random Value or Request Token) MUST be observed by the required number of Network Perspectives defined in the "# of Network Perspectives and Quorum Requirements" table, otherwise the certificate MUST NOT be issued.

---

Reverse Address Lookup (defined in 3.2.2.5.3):

This method involves a DNS lookup to obtain information about which domain is associated with an IP address.

“Corroborate” means the domain name retrieved via the reverse DNS lookup MUST be observed by the required number of Network Perspectives defined in the "# of Network Perspectives and Quorum Requirements" table, otherwise the certificate MUST NOT be issued.

---

ACME “http-01” method for IP Addresses (defined in 3.2.2.5.6):

This method involves observing changes to website content.

“Corroborate” means the corresponding challenge information (e.g., Random Value or Request Token) MUST be observed by the required number of Network Perspectives defined in the "# of Network Perspectives and Quorum Requirements" table, otherwise the certificate MUST NOT be issued.

---

ACME “tls-alpn-01” method for IP Addresses (defined in 3.2.2.5.7):

This method involves establishing a TLS connection.

“Corroborate” means the corresponding challenge information (e.g., Random Value or Request Token) MUST be observed by the required number of Network Perspectives defined in the "# of Network Perspectives and Quorum Requirements" table, otherwise the certificate MUST NOT be issued.

---

We felt addressing these three points would improve the clarity and security of this draft while remaining consistent with the intent and specification that was agreed upon in the work team discussions and google doc collaboration.

[birgelee]

One additional point, "Table: Defining Corroborating Domain Validation Evidence" has the line:

---

IP Address (defined in 3.2.2.4.8):

This method involves observing A or AAAA records in DNS.

“Corroborate” means the corresponding challenge information (e.g., Random Value or Request Token) MUST be observed by the required number of Network Perspectives defined in the "# of Network Perspectives and Quorum Requirements" table, otherwise the certificate MUST NOT be issued.

---

While I think an informed reader can interpret the intent of this table line, I felt it was a little confusing because, as stated in the first sentence the method involves observing A or AAAA records in DNS. However, the definition of Corroborate is referring to challenge information like random values. I think it is a somewhat strange wording to consider a domain's operating IP address as challenge information. I think it might make more sense to change the table entry to:

---

IP Address (defined in 3.2.2.4.8):

This method involves observing A or AAAA records in DNS.

“Corroborate” means an IP address controlled by the applicant in accordance with Section 3.2.2.5 MUST be observed by the required number of Network Perspectives defined in the "# of Network Perspectives and Quorum Requirements" table, otherwise the certificate MUST NOT be issued. The observed IP address controlled by the applicant does not need to be the same across various Network Perspectives.

---

I also want this definition to clearly allow for applicants that have control of multiple IP addresses to only have one of them seen at each perspective as this may be the case with geographic load balancing.

[ryancdickson]

Thank you @birgelee and the rest of the Princeton Team!

I've updated the draft to include your suggestions. Comments from the community on these changes are welcome.

[aarongable]

It feels like this is saying two different things. I generally interpret "result" to mean "DCV pass/fail" or "CAA allow/disallow". But the parenthetical seems to define "result" as "corroborate/disagree". Which do we prefer?

Notably, if audit logs are being generated directly by systems which are performing MPDV, they probably don't know whether they're corroborating or not, because at the time they get their result they don't know whether the Primary Domain Validation Determination has succeeded or not.

[dzacharo]

The domain validation method used is captured in another existing requirement (Section 3.2.2.4: "CAs SHALL maintain a record of which domain validation method, including relevant BR version number, they used to validate every domain.").

I agree with Aaron and want to highlight that each Network Perspective acts independently of each other. The only meaningful logging from each Network Perspective would be an identifier (first bullet), the attempted domain name (second bullet), the requested type (DNS record or file downloaded) and the value obtained for each request. That would significantly increase the logging volume for CAs.

Alternatively, the CA could log the result of the corroboration based on the "Network Perspectives and Quorum Requirements" table, and capture:

• the identifiers that uniquely identify the perspectives used
• the attempted Domain Name
• the corroboration result (2 out of 3, 3 out of 3, 2 out of 4, etc.)

[ryancdickson]

It looks like this comment thread is split (not sure why). There's an additional comment from Henry below.

Attempted to rephrase to foster continued discussion:

7. Multi-Perspective Domain Validation attempts from each Network Perspective, minimally recording the following information:

   • an identifier that uniquely identifies the perspective used
   • the attempted domain name
   • the result of the attempt (i.e., "DCV pass/fail, CAA allow/disallow")

8. Multi-Perspective Domain Validation quorum results for each attempted domain name represented in a Certificate request (i.e., "3/4" which should be interpreted as "3 out of 4 attempted Network Perspectives corroborated the Primary Domain Validation Determination and Primary CAA Determination).

Goals:

• Clarify the expected result of an attempt
• Clarify that CAs should log a summary of the quorum results
• Ensure data is available to help failure analysis.

[dzacharo]

Although I understand the semantics of SHALL and SHOULD, this style of linking requirements with SHALL/SHOULD is not used anywhere else in the document and does not form complete sentences. I have no strong feelings about this but it's not a style I've seen in other standards.

[ryancdickson]

Open to feedback from others on this topic.

I generally find bulleted lists more readable than paragraphs, and thought this format would be easier for CA owners to consume. Understandably, not everyone shares this same preference.

[dzacharo]

Also, to Aaron's point, we should replace "computing systems performing Multi-Perspective Domain Validation" with just "Network Perspectives".

If the "computing systems" element needs to be included in the "Network Perspective" concept, we should update the definition.

[birgelee]

I am fine with the change here from "computing systems performing Multi-Perspective Domain Validation" to "Network Perspective," but I think some tweaking of the definition of "Network Perspective" is needed. Specifically a "Network Perspective" is defined as "A configuration for sending outbound Internet traffic..." I think it is somewhat strange to thing about these requirements like a penetration test being enforced on a configuration. Maybe to resolve this we could update the first line of the "Network Perspective" definition to read "A system for sending outbound Internet traffic..."

[dzacharo]

The domain validation method used is captured in another existing requirement (Section 3.2.2.4: "CAs SHALL maintain a record of which domain validation method, including relevant BR version number, they used to validate every domain.").

I agree with Aaron and want to highlight that each Network Perspective acts independently of each other. The only meaningful logging from each Network Perspective would be an identifier (first bullet), the attempted domain name (second bullet), the requested type (DNS record or file downloaded) and the value obtained for each request. That would significantly increase the logging volume for CAs.

Alternatively, the CA could log the result of the corroboration based on the "Network Perspectives and Quorum Requirements" table, and capture:

• the identifiers that uniquely identify the perspectives used
• the attempted Domain Name
• the corroboration result (2 out of 3, 3 out of 3, 2 out of 4, etc.)

[birgelee]

I like Dimitris' point about logging the result of the corroboration based on the "Network Perspectives and Quorum Requirements" table. The only thing I might add is that in addition to the corroboration result and the identifiers of the perspectives used, I think it would be valuable to have information on which perspectives corroborated and which didn't (as opposed to just the corroboration count). If there was an incident, I think this would be useful for forensics.

[geegeea]

Based on this table, the quorum requirement is 50% for 2 corroborating perspectives, 67% for 3 corroborating perspectives, 75% for 4 corroborating perspectives, 80% for 5 corroborating perspectives, and back down to 67% for 6 corroborating perspectives.

This may push the community towards using 2, 3, or 6 corroborating perspectives instead of 4 or 5 as it allows for a higher tolerance of false negatives. In Google's MPDV implementation, we require 3 out of 5 perspectives to pass. We haven't done a full study of the security/false positive tradeoff, however, we see increased false negatives when increasing the quorum requirement to 4.

Is it possible to require a constant percentage for quorum? For example, 60%. Then the quorum requirements will be 2/2, 2/3, 3/4, 3/5, 4/6, etc.

[ryancdickson]

@geegeea - thanks for this suggestion, a consistent quorum "score" is an interesting idea - and presents an opportunity to simplify the requirements.

I'll study this further to understand the impact of this proposal and will report back.

[birgelee]

I see the 2, 3 and 4 remote perspectives lines as largely intermediate steps to allow the ecosystem to adjust to this new requirement. In the current draft, none of these lines can be used after 9/15/2026. My understanding is that the 2 collaborating perspective configuration has a 50% quorum simply to offer an easy transition step before quorums increase. Thus, I don’t think there is too much of a push to 2 or 3 corroborating perspectives in the long run and I personally would keep these lines untouched to continue to offer easy transition steps.

As for making the long-term quorum a fixed percent instead of N-2, I think this does make sense. I feel there are pros and cons of each approach. One nice thing with the N-2 quorum is that as perspective counts increase security keeps continuously improving. If a fixed percentage quorum is used, this will always have to be rounded to an integer and this creates slightly lower and higher security perspective counts. On the flip side, some could say the 2-N quorum arguably discourages people from deploying larger perspective counts as while it increases security, false positives may also increase.

I was somewhat delayed answering this as I wanted to run additional data to tell from a security perspective how the 3/5 quorum performed. Overall it is much stronger than not implementing this system all together, but I personally think it does leave some room for improvement that could be capitalized by requiring a 4/5 quorum. Below I list the resilience of the median domain (as defined in our paper https://arxiv.org/pdf/2302.08000.pdf) under different quorum policies with 5 remote perspectives. Resilience can loosely be thought of as the fraction of potential adversaries on the Internet from which a domain is protected against equally-specific BGP attacks. In order to leverage the data available from our paper, I used the Let’s Encrypt vantage points and two optimal expansions we recommended (although I could potentially compute this under different perspective sets if that is of interest).

Primary perspective only (no MPDV): Median Resilience: 0.5411

5 Remote Perspectives Allowing 2 to Fail: Median Resilience: 0.9021

5 Remote Perspectives Allowing 1 to Fail: Median Resilience: 0.9751

5 Remote Perspectives Allowing None to Fail: Median Resilience: 0.9901

I have also attached a domain resilience CDF showing these different scenarios.

I also ran a similar set of simulations for 6 perspective sets with different quorums:

6 Remote Perspectives Allowing 2 to Fail: Median Resilience: 0.9221

6 Remote Perspectives Allowing 1 to Fail: Median Resilience: 0.9771

6 Remote Perspectives Allowing None to Fail: Median Resilience: 0.9921

As @geegeea correctly points out this is a security-usability tradeoff question and while 3/5 offers decent security, stronger security can definitely be achieved with 4/5 and 4/6 remote perspective although this can come at an increased rate of false positives.

I also want to mention that we noticed with Let’s Encrypt there were several ways to significantly reduce false positives. Many false positives are transient due to DNS propagation delays. User retries fixed a large fraction of these issues at Let’s Encrypt. Automatic CA retries can also potentially reduce these false positives. Google Trust Services utilizes a very different infrastructure for performing MPDV than Let’s Encrypt and there may be a different false positive rate associated with this approach (our team at Princeton would be happy to learn more about your deployment experience and share some successful strategies from the Let’s Encrypt deployment). Finally, it may be more forgiving on the false positive count to simply add an additional perspective in a highly-reliable location thus putting the total perspective count at 6 and still allowing 2 failures than to change the quorum to 1 failure with 5 perspectives.

[birgelee]

I wanted to comment on thesis lines in light of some of the discussion on the CAB Forum public list. Our team at Princeton does see multi-perspective CAA checking as a core part of multi-perspective domain validation which offers a noticeable security improvement against BGP attacks and attacks that are chained with BGP attacks.

Specifically, CAA allows for a domain to constrain its BGP attack surface to only DNS target IP addresses and avoid attacks posed by vulnerable A-record IP addresses. In the absence of CAA records, an adversary aiming to obtain a misissued certificate for example.com can either launch a BGP attack against an authoritative nameserver for example.com or an IP address pointed to by example.com’s A record (both of these strategies have been seen in the wild). Domains containing CAA records that either 1) specify an account ID, 2) specify validation methods that only rely on DNS or 3) contain no issue (i.e., “issue ;”) are immune to attacks on A records and can only be hijacked via attacks on DNS infrastructure. We do see all three of these configurations on real TLS domains (https://blog.apnic.net/2023/06/28/whose-certificate-is-it-anyway/). Our data suggests that the DNS attack surface is in fact smaller than the A record attack surface. In the absence of multi-perspective CAA checking this, added security can easily be downgraded as the adversary need only fool the CAA lookup from the CA’s primary perspective.

In addition to reducing the attack surface to equally-specific BGP attacks, we see CAA records as providing security against a broad range of attacks on domain control validation which may unexpectedly arise in the future. Some historical domain validation vulnerabilities that CAA records could have protected a domain against (sampled with no particular intention) include the WoSign any-port behavior (https://wiki.mozilla.org/CA/WoSign_Issues#Issue_L:_Any_Port_.28Jan_-_Apr_2015.29) and the ACME TLS-SNI-01 vulnerability (https://labs.detectify.com/2018/01/12/how-i-exploited-acme-tls-sni-01-issuing-lets-encrypt-ssl-certs-for-any-domain-using-shared-hosting/). Reducing the risk posed by vulnerabilities in domain control validation methods or CAs which a domain does not use to obtain its own certificates is an important benefit of CAA records. If CAA records are not checked from multiple network perspectives, this benefit can easily be undermined. Upon discovering a vulnerable domain control validation practice anywhere in the PKI ecosystem, an adversary can quite easily target a domain with a protecting CAA record by performing a BGP hijack that fools the primary perspective and then exploiting the vulnerable domain control validation procedure to obtain a misissued certificate. In both of these historical examples, multi-perspective domain control validation would have not mitigated these domain control validation vulnerabilities, but multi perspective CAA checking could have caught the BGP attack that was used to evade the security offered by the CAA records.

Furthermore, beyond simply validation practices that were ultimately deemed unacceptable, different validation procedures give the authority to obtain a certificate for a domain to different groups of administrators (or software stacks). Email validation can be completed by mail-server admins and people who respond to admin email addresses, HTTP validation can be completed by web server admins, DNS validation requires DNS server access etc… A large organization can use CAA to allow only specific systems or admins the authority to obtain a certificate. Even if the PKI behaves as intended, this is another security protection that CAA offers which can be more easily downgraded by a BGP attack if CAA records are not checked from multiple perspectives.

In short, CAA offers high-security domains the option of minimizing their attack surface and we feel it is important (particularly for facilitating the continued growth of CAA) this security measure is not easily downgraded.

I do see Dimitris’ point about CAA checks having to be repeated for each subdomain even though several subdomains can be validated under a single DNS validation for a base domain. However, I see this phenomena as largely unrelated to multi-perspective checks and more tied to the CAA parsing behavior which requires CAA to be checked for each subdomain. Even though as Dimitris points out adding multi-perspective CAA checks does cause four times as many CAA checks, these checks can be run in parallel to the primary CAA check to avoid contributing significantly to latency (in fact, with Let’s Encrypt’s implementation remote validation usually resolves faster than primary validation causing no impact to median latency). The 50x increase comes from CAA semantics unrelated to multi-perspective checking.

That said, I still think there might be a way to make multi-perspective CAA checking significantly easier to implement while having a negligible impact on security. Aaron’s response mentioned that due to the time constraints around the finalize order for certificates, multi-perspective CAA checking was only done at validation time (if a CAA record has to be rechecked at issuance time because it expired since domain control validation occurred Let’s Encrypt does not do this recheck from multiple vantage points). I know in principle CAA checking needs to be done before issuance sometimes unassociated with validation as the period of validity for a CAA record check is less than the reuse period for domain control validation. However, I feel that the security would not be sufficiently compromised if multi-perspective CAA checking was simply bundled with multi-perspective domain control validation. I feel this would make implementations easier as the multi-perspective infrastructure would only need to be interacted with once (during validation time) where it could collect corroborating CAA evidence at the same time. If this validation data is then reused to issue a certificate at a later time (after which the CAA record check would be considered stale), only the primary perspective would need to recheck.

Along these lines I propose something like:

Suggested change

[Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) and [Section 3.2.2.5](#3225-authentication-for-an-ip-address) describe the validation methods that require the use of Multi-Perspective Domain Validation and how a Network Perspective can corroborate the Primary Domain Validation Determination. To corroborate the Primary CAA Determination, a Network Perspective MUST perform a CAA lookup that concludes the CA can issue a certificate to the domain in question.

[Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) and [Section 3.2.2.5](#3225-authentication-for-an-ip-address) describe the validation methods that require the use of Multi-Perspective Domain Validation and how a Network Perspective can corroborate the Primary Domain Validation Determination. To corroborate the Primary CAA Determination, a Network Perspective MUST perform a CAA lookup that concludes the CA can issue a certificate to the domain in question. A CA MAY use corroborating evidence for CAA record compliance for a period equal to the period of validity for Validation of Domain Authorization or Control specified in [Section 4.2.1](#421-performing-identification-and-authentication-functions).

that specifies CAA corroboration does not need to be checked more often than domain control validation.

[birgelee]

I see the 2, 3 and 4 remote perspectives lines as largely intermediate steps to allow the ecosystem to adjust to this new requirement. In the current draft, none of these lines can be used after 9/15/2026. My understanding is that the 2 collaborating perspective configuration has a 50% quorum simply to offer an easy transition step before quorums increase. Thus, I don’t think there is too much of a push to 2 or 3 corroborating perspectives in the long run and I personally would keep these lines untouched to continue to offer easy transition steps.

As for making the long-term quorum a fixed percent instead of N-2, I think this does make sense. I feel there are pros and cons of each approach. One nice thing with the N-2 quorum is that as perspective counts increase security keeps continuously improving. If a fixed percentage quorum is used, this will always have to be rounded to an integer and this creates slightly lower and higher security perspective counts. On the flip side, some could say the 2-N quorum arguably discourages people from deploying larger perspective counts as while it increases security, false positives may also increase.

I was somewhat delayed answering this as I wanted to run additional data to tell from a security perspective how the 3/5 quorum performed. Overall it is much stronger than not implementing this system all together, but I personally think it does leave some room for improvement that could be capitalized by requiring a 4/5 quorum. Below I list the resilience of the median domain (as defined in our paper https://arxiv.org/pdf/2302.08000.pdf) under different quorum policies with 5 remote perspectives. Resilience can loosely be thought of as the fraction of potential adversaries on the Internet from which a domain is protected against equally-specific BGP attacks. In order to leverage the data available from our paper, I used the Let’s Encrypt vantage points and two optimal expansions we recommended (although I could potentially compute this under different perspective sets if that is of interest).

Primary perspective only (no MPDV): Median Resilience: 0.5411

5 Remote Perspectives Allowing 2 to Fail: Median Resilience: 0.9021

5 Remote Perspectives Allowing 1 to Fail: Median Resilience: 0.9751

5 Remote Perspectives Allowing None to Fail: Median Resilience: 0.9901

I have also attached a domain resilience CDF showing these different scenarios.

I also ran a similar set of simulations for 6 perspective sets with different quorums:

6 Remote Perspectives Allowing 2 to Fail: Median Resilience: 0.9221

6 Remote Perspectives Allowing 1 to Fail: Median Resilience: 0.9771

6 Remote Perspectives Allowing None to Fail: Median Resilience: 0.9921

As @geegeea correctly points out this is a security-usability tradeoff question and while 3/5 offers decent security, stronger security can definitely be achieved with 4/5 and 4/6 remote perspective although this can come at an increased rate of false positives.

I also want to mention that we noticed with Let’s Encrypt there were several ways to significantly reduce false positives. Many false positives are transient due to DNS propagation delays. User retries fixed a large fraction of these issues at Let’s Encrypt. Automatic CA retries can also potentially reduce these false positives. Google Trust Services utilizes a very different infrastructure for performing MPDV than Let’s Encrypt and there may be a different false positive rate associated with this approach (our team at Princeton would be happy to learn more about your deployment experience and share some successful strategies from the Let’s Encrypt deployment). Finally, it may be more forgiving on the false positive count to simply add an additional perspective in a highly-reliable location thus putting the total perspective count at 6 and still allowing 2 failures than to change the quorum to 1 failure with 5 perspectives.

[ryancdickson]

This PR has been obsoleted by #8.

Closing, but preserving this PR due to useful comment history.