Version 2: Add Multi-Perspective Domain and CAA Checking Requirements to the BRs #8
Conversation
Co-authored-by: Aaron Gable <aaron@aarongable.com>
Co-authored-by: Aaron Gable <aaron@aarongable.com>
Co-authored-by: Aaron Gable <aaron@aarongable.com>
Co-authored-by: Aaron Gable <aaron@aarongable.com>
Co-authored-by: Aaron Gable <aaron@aarongable.com>
Co-authored-by: Aaron Gable <aaron@aarongable.com>
Co-authored-by: Aaron Gable <aaron@aarongable.com>
More consistent use of "primary determinations."
Extend audit/logging requirements to IP addresses
Co-authored-by: Aaron Gable <aaron@aarongable.com>
| - Undergo a Penetration Test on at least an annual basis. | ||
| - Apply recommended security patches within six (6) months of the security patch's availability, unless the CA documents that the security patch would introduce additional vulnerabilities or instabilities that outweigh the benefits of applying the security patch. | ||
|
|
||
| Beyond the above considerations, computing systems performing Multi-Perspective Issuance Corroboration are considered outside of the audit scope described in Section 8 of these Requirements. |
There was a problem hiding this comment.
Has anyone asked WebTrust/ETSI reps for input on how they will interpret this paragraph? They may be able to suggest changes that clarify what should be audited or to make the requirements more auditable.
There was a problem hiding this comment.
We had a meeting with Tim (BDO) 2 or 3 months ago to collect general recommendations for the text, but did not focus specifically on interpretations.
I'll take action to follow-up with a broader set of audit stakeholders.
docs/BR.md
Outdated
|
|
||
| Results or information obtained from one Network Perspective MUST NOT be reused or cached when performing validation through subsequent Network Perspectives (e.g., different Network Perspectives cannot rely on a shared DNS cache to prevent an adversary with control of traffic from one Network Perspective from poisoning the DNS cache used by other Network Perspectives). | ||
|
|
||
| [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 Issuance Corroboration and how a Network Perspective can corroborate the Primary Domain Validation Determination and the Primary CAA Determination. 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). |
There was a problem hiding this comment.
RFC 8659 states:
The search for a CAA RRset climbs the DNS name tree from the specified label up to, but not including, the DNS root "." until a CAA RRset is found.
This means that for x.y.z.example.com the following zones are checked for CAA records, until a record is found.
- x.y.z.example.com
- y.z.example.com
- z.example.com
- example.com
- com
If the domain example.com is added and used for domain control validation (including multi-perspective CAA checks), the attacker can still bypass the multi-perspective CAA check by faking the any of the more specific zones with a new CAA record, for example on x.y.z.example.com unless multi perspective CAA checking is done at the time of issuance.
The other challenge might be that at the time of domain control validation the context of the certificate might not be known, so this would require checking for issue and issuewild and potentially other CAA properties and to record the type of certificates that this domain would be authorized for.
The suggestion was to perform multi perspective CAA checking at the time of domain validation control to avoid the performance impact, but it's the question if this really helps as there are different FQDNs and types of certificates to consider that might be unknown at the time of performing domain control validation.
There was a problem hiding this comment.
Thanks for bringing this up. As I understand this comment there are largely see two factors worth considering:
1: at time of domain control validation, the exact subdomain may not be known, so a CAA recheck would have to be performed at issuance time on the subdomain.
2: at time of domain control validation, the certificate type may not be known so the whether the issue or issuewild field is used cannot be determined.
My first thoughts on these two points is that cases where point 1 is applicable simply can't benefit as much from this CAA check at DV time clause. Potentially if CAA evidence was collected from multiple perspectives for "example.com" and a customer requested a certificate for sub.example.com, the CAA evidence for example.com could be reused preventing the need to query recursively up the DNS graph from multiple perspectives. However, in my opinion, as @vanbroup mentioned, a query for sub.example.com in CAA would have to be done at time of issuance.
Point 2 is interesting as well, and I could see it becoming more involved if CAA record types grow in complexity. My personal thoughts on this are that the certificate type concern is not too big of an issue. First, there may be some more advanced APIs, but my general understanding of DNS is that a question like "example.com IN CAA" will always return the entire CAA DNS record set (having knowledge of the entire record set is also required in case there are critical flag records). Thus, whenever a CA makes this query, it will retrieve CAA records with both the "issue" and "issuewild" tags. With this in mind, I think the resolution to point 2 is simply to cache the values of the CAA records fetched from multiple vantage points (as opposed to a can issue or can't issue binary flag) and then resolve the issuance status based on the cached values and certificate type at issuance time.
Overall I still feel it makes sense to have this performance optimization in there. I understand there are some cases where it can't be realized and CAA records would still have to be checked from multiple perspectives at issuance time, but I feel checking CAA records from multiple perspectives is very important for the security of the PKI and the future growth of CAA records. I think any way to reduce the latency/resource overhead without compromising security is beneficial.
There was a problem hiding this comment.
I agree that you could cache the CAA records (assuming DNSSec signatures etc. are validated), and you could potentially do additional checks based on likelihood (like including an MP CAA check for www.example.com).
But this would not come for free and require quite a bit of additional implementation work (code that could fail), and meta data for each domain.
I think it would be good to dive a bit deeper into the potential impact and realistic performance gain.
Maybe it could be described as that when MP CAA has been performed it can be re-used until the current domain name validation expires. This way you would only need do the MPV CAA checking at issuance time when it has not been performed since the last domain control validation check.
This would allow the CA to do MP CAA checking at domain control validation, but would also allow them to perform it at issuance time and re-use it in both cases.
There was a problem hiding this comment.
@vanbroup I do appreciate the points about additional code complexity and extra meta data (which can add up at large scale).
I wanted to take a step back from this problem and actually think about its impact on the threat space. I think one important thing to consider is that the two cases being discussed are related to domain validation reuse for subdomains and wildcard certificate types. My understanding of the BRs is that both of these cases require some form of validation of DNS information (not just control of a server running at that domain) which would be checked from multiple vantage points. Given the adversary can demonstrate this level of control over DNS, the adversary likely also has the ability to also spoof CAA records. I think there still is some attack surface left open by not rechecking sub-domain CAA or issuewild records from multiple vantage points (e.g., an adversary could have compromised domain validation by attacking an external channel like email without actually controlling the target domain's DNS records), but I also think this is not a huge threat surface.
@vanbroup can you put in a suggested change with the language you are proposing. I like the idea you had to permit reuse since the last validation and also permit rechecking at issuance time and caching as an option.
Make it clear that perspectives used to corroborate the determination made by the primary MUST be distinct from the primary.
docs/BR.md
Outdated
| @@ -763,12 +770,20 @@ If a Random Value is used, the CA SHALL provide a Random Value unique to the Cer | |||
| i. 30 days or | |||
| ii. if the Applicant submitted the Certificate request, the time frame permitted for reuse of validated information relevant to the Certificate (such as in [Section 4.2.1](#421-performing-identification-and-authentication-functions) of these Guidelines or Section 11.14.3 of the EV Guidelines). | |||
|
|
|||
| CAs using this method MUST implement Multi-Perspective Issuance Corroboration as specified in Section 3.2.2.9. To count as corroborating, a Network Perspective MUST observe: | |||
| - the same challenge information (i.e. Random Value or Request Token) as the Primary Network Perspective; and | |||
| - evidence confirming the CA's authority to issue as determined by the Primary Network Perspective, as specified in Section 3.2.2.8. | |||
There was a problem hiding this comment.
(this comment is applicable to all modified DCV methods)
I find this reference to the CAA requirements as defined in 3.2.2.8 rather confusing. In many cases, the validation of a single Authorization Domain Name is used for the validation of potentially many domains. For example, a single successful validation of "example.com" via method 7 would be sufficient to demonstrate control of many subdomains under "example.com", some (or all) of which could be in different zones from "example.com" itself. However, 3.2.2.8 prescribes that the CA perform the CAA algorithm for all SANs to be included in the certificate regardless of how they were validated.
By tying the CAA MPIC requirement with the DCV requirement, it becomes unclear which domain names must be checked for MPIC when performing the CAA checks under 3.2.2.8. To ensure clarity on the requirements, I recommend modifying 3.2.2.8 to define the MPIC obligations specifically for CAA there.
There was a problem hiding this comment.
3.2.2.9 (the new MPIC section) includes...
Each corroborating Network Perspective MUST independently verify:
a. the presence of the expected 1) Random Value, 2) Request Token, 3) IP Address, or 4) Contact Address, as required by the relied upon validation method specified in Sections 3.2.2.4 and 3.2.2.5; and
b. the CA's authority to issue to the requested domain(s), as specified in Section 3.2.2.8.
Given the bolded language above, it seems like we could remove the CAA references added in the 3.2.2.4.X subsections (e.g., "evidence confirming the CA's authority to issue as determined by the Primary Network Perspective, as specified in Section 3.2.2.8.")?
Would that address your concern?
There was a problem hiding this comment.
I think there needs to be, at a minimum, a reference to section 3.2.2.9 in section 3.2.2.8. This reference would serve as an indicator to readers that they must also read 3.2.2.9 to correctly implement CAA checking.
There was a problem hiding this comment.
Added this update to address the above concern. What do you think?
Beyond the above change, this commit removes the CAA references added in 3.2.2.4.x as they relate to MPIC - and also adds MPIC being in scope of 3.2.2.4.16 (Phone Contact with DNS TXT Record Phone Contact), which the work team identified was in-scope of this effort.
There was a problem hiding this comment.
I think its worth having a more general discussion of this as well as a more detailed review of the language in the draft. Our group at Princeton feels that including some form of multi-perspective checking for CAA records is quite important. CAA records establish a CA's permission to issue and issuing in violation of a CAA record is a serious security breach.
However, we are aware there are some nuances regarding the implementation of CAA record checking in comparison to DV. Particularly, because CAA record checks must be done for all subdomains and have a shorter validity than a domain control validation check, CAA record checks may have to be done at issuance time for a domain that has already been validated. While it is clearly a stronger security stance and arguably a simpler standard to use multiple perspectives for all CAA checks, we felt it might meaningfully reduce the implementation burden to only perform MP-CAA checks at validation time (this is the current deployment at Let's Encrypt and I would be curious to also hear how Google Trust Services handles this case). Domain Validation contains more high-latency steps which depend on external systems than issuance does. To me this seems to facilitate an easier implementation.
As several have commented in the GitHub, only checking CAA records at validation time potentially raises several issues.
The first issue is the validity duration of a CAA check which is shorter than that of issuance. If MPCAA checking is only done at validation time, then this check would have to have validity equal to that of domain control validation to avoid a recheck at issuance time. Personally I think only performing a primary perspective CAA recheck at issuance time does not significantly change the security of the system. Potentially it allow an adversary to use a BGP attack to expand the time window after a malicious validation during which the adversary can request a certificate. However, this phenomena exists even with the shorter CAA checking window and other factors like DNS caching can cause this type of behavior even if checks were done more frequently. Personally I think this alone does not do much to justify rechecks at issuance time.
The second complication is that some validation methods can be used to validate arbitrary subdomains (while a CAA check must be done on each subdomain requested). This is a concern Dimitris brought up in the CAB Forum public list: https://lists.cabforum.org/pipermail/validation/2023-June/001904.html . In order to avoid all issuance time MPCAA checks, an MPCAA check would have to cover all subdomains. This is contrary to the CAA RFC that gives the CAA record of subdomains priority over parent domains. The vulnerability presented here is that an adversary can potentially downgrade the CAA record of a subdomain to that of its parent domain using an equally-specific BGP attack. This is clearly not ideal, but I still think that this is vastly preferable to dropping MPCAA record checking entirely. Also, in this scenario the adversary would be authorized to get a certificate for the parent domain (because it had completed domain control validation for that domain and the parent domain had a CAA record that permitted issuance) so this is largely about developing protections for a subdomain of a domain that an adversary has already compromised.
The final complication regards certificate types (i.e., wildcard vs standard) given that the interpretation of CAA records (particularly record sets with the issuewild tag) depends on the type of certificate a CA is signing (whereas some forms of domain validation can be used for either one). Potentially a CA may have checked a CAA record at validation time and been permitted to issue a standard, non-widlcard, certificate for that domain. At a later time a subscriber may request a wildcard certificate for the same domain. In some implementations this may require rechecking the CAA record to confirm that the CA is compliant with any issuewild tags. Personally I think there is potentially technical answer to this complication which is to store information about whether a CA can issue standard or wildcard certificate based on an initial CAA query (even if a subscriber is only requesting a standard certificate). One factor that facilitates this is that the same DNS query which is used to request the initial CAA record will both issuewild and issue tags. Storing this extra info would only require one additional bit of information on the result of an MPCAA lookup and would eliminate the need to perform additional MPCAA lookups at issuance time due to this reason.
Given all of these points and @CBonnell 's point about detaching the CAA checking requirement from the DV requirement, an idea that comes to mind is to add additional exceptions for the CAA checking requirement in 3.2.2.9:
Line 1054 could be modified to read:
Section 3.2.2.4 and Section 3.2.2.5 describe the validation methods that require the use of Multi-Perspective Issuance Corroboration and how a Network Perspective can corroborate the outcomes determined by the Primary Network Perspective. A CA MAY use corroborating evidence for CAA record compliance for a period of 398 days. If an applicant has completed domain control validation for a domain and a CA has collected corroborating evidence that gives the CA permission to issue a certificate for that domain as defined in Section 3.2.2.8 and 3.2.2.9, the CA does not need to corroborate the CAA determination of any subdomains for certificate requests from the same applicant.
There was a problem hiding this comment.
@CBonnell - Any opinion on @birgelee's suggestion above?
"Section 3.2.2.4 and Section 3.2.2.5 describe the validation methods that require the use of Multi-Perspective Issuance Corroboration and how a Network Perspective can corroborate the outcomes determined by the Primary Network Perspective. A CA MAY use corroborating evidence for CAA record compliance for a period of 398 days. If an applicant has completed domain control validation for a domain and a CA has collected corroborating evidence that gives the CA permission to issue a certificate for that domain as defined in Section 3.2.2.8 and 3.2.2.9, the CA does not need to corroborate the CAA determination of any subdomains for certificate requests from the same applicant."
| @@ -1008,6 +1063,62 @@ CAs are permitted to treat a record lookup failure as permission to issue if: | |||
|
|
|||
| CAs MUST document potential issuances that were prevented by a CAA record in sufficient detail to provide feedback to the CAB Forum on the circumstances, and SHOULD dispatch reports of such issuance requests to the contact(s) stipulated in the CAA iodef record(s), if present. CAs are not expected to support URL schemes in the iodef record other than mailto: or https:. | |||
|
|
|||
| #### 3.2.2.9 Multi-Perspective Issuance Corroboration | |||
There was a problem hiding this comment.
I'm unable to leave a comment on line 1058 (https://github.com/ryancdickson/staging/pull/8/files#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1058) since it wasn't modified, so I'll leave it here:
My understanding is that CAs will be able to issue if the lookup failures for both the Primary and Secondary Network Perspectives are consistent. For example, if the Primary Perspective receives a SERVFAIL in response to a CAA lookup for "example.com" and the Secondary Network Perspectives receive the same, then this can be treated as permission to issue (assuming, of course, there's no DNSSEC chain to the ICANN root and the CA infrastructure isn't experiencing issues). However, if the Primary Perspective observes a SERVFAIL and the Secondary Perspectives receive a NOERROR/NXDOMAIN, then this cannot be treated as permission to issue as the Primary and Secondary Perspectives have received differing responses.
Is this correct, or is the expectation different here?
There was a problem hiding this comment.
While this is one interpretation of the text, my original thought was that it would be OK for a CA to proceed with issuance under the second scenario described. Even though the error signals from the different perspectives are distinct, in the absence of a trusted DNSSEC chain, both of these can be treated as permission to issue. Thus, my original interpretation of this was "corroborates" is essentially a binary state and both the primary and secondary perspectives here interpret their DNS response as permission to issue implying issuance can proceed.
While requiring matching error messages or matching responses is clearly a stricter policy, I do not think it adds too much security, and I worry a bit about it introducing false positives. If an adversary has launched a BGP hijack which effects some of a CA's perspectives, it has the liberty of choosing what types of DNS responses it wants to generate and could likely generate responses that match the victims' (bypassing this sameness check). On the benign side, in our last study we noticed discrepancies in DNS configurations when probed from multiple perspectives. Many DNS providers rely heavily on IP anycast so the DNS queries from the different perspectives are often being answered by different servers (which can have different configurations or out-of-date zone files). Thus, while varying error messages may seemingly indicate an attack, I could also see it arising in benign circumstances, and I believe an adversary could avoid this check.
Additionally, we considered differentiating between different types of responses in the domain validation check, but ultimately backed away from it and went more towards reducing each vantage point's response to a binary state which is then processed in the quorum policy. I personally feel for consistency and simplicity it would also make sense to use that reasoning here.
I would be in favor of adding language to clarify that permission to issue is a binary state (i.e., can issue or can't issue) which is then processed by the quorum policy.
There was a problem hiding this comment.
Line 1061 of the current draft text says:
Multi-Perspective Issuance Corroboration attempts to corroborate the determinations made by the Primary Network Perspective from multiple additional Network Perspectives
It is my understanding that this explanatory text is stating that the Primary Network Perspective provides the canonical response, and the requisite number of additional Network Perspectives MUST provide the same response to corroborate the response as retrieved by the Primary Network Perspective. My understanding of the rationale is that the Primary Network Perspective is audited under the NetSec audit regime, whereas secondary Network Perspectives need not be audited. Thus, there is a higher level of assurance from the responses provided by the Primary as opposed to secondary Network Perspectives.
Given this rationale, I interpreted the CAA allowance for issuance upon encountering lookup errors as "the requisite number of secondary Network Perspectives must observe the failure observed by the Primary Network Perspective in order to be treated as permission to issue". I think clarifying language is needed if the intended requirement is actually looser.
There was a problem hiding this comment.
@CBonnell - would better establishing context for "determinations" (and doing so at a sufficient level of detail that's focused on the outcome of the checks) address this concern?
From: Multi-Perspective Issuance Corroboration attempts to corroborate the determinations made by the Primary Network Perspective from multiple additional Network Perspectives before Certificate issuance.
To: Multi-Perspective Issuance Corroboration attempts to corroborate the determinations (i.e., domain validation pass/fail, CAA permission/prohibition) made by the Primary Network Perspective from multiple additional Network Perspectives before Certificate issuance.
There was a problem hiding this comment.
Apologies for missing this; it apparently got lost in a flurry of Github notifications. I don't think the proposed language change would address the difference in interpretation for the "CAA lookup failure" case as discussed above in this comment thread. I interpret the proposed language the same as the previous language: a CAA lookup failure by the Primary Network Perspective while the Secondary Perspectives observe a lookup success cannot be treated as permission to issue, as the Secondary Perspective results do not corroborate the Primary Perspective's lookup failure.
There was a problem hiding this comment.
Maybe a solution could be to add @ryancdickson 's language but also put an explicit statement to cover this case in the section on MPIC CAA checking:
When corroborating a CAA check from multiple Network Perspectives, for the result of the CAA check at an additional Network Perspective to count as corroborating the Primary Network Perspective, the CAA check from the additional Network Perspective MUST be interpreted as permission to issue as outlined in Section 3.2.2.8. However, a CA MAY count the response of an additional Network Perspective as corroborating the Primary Network Perspective even if CAA records seen by the additional Network Perspective do not match the records seen by the Primary Network Perspective or one or both of the additional Network Perspective or Primary Network Perspective experience an acceptable CAA record lookup failure as defined in Section 3.2.2.8.
Personally I feel adding language along these lines to explicitly allow this case would sufficiently clarify things in the document. Thinking more on this topic I do feel that some of the confusion comes from the use of the word "corroborate" which implies some level of similarity in responses (which makes sense in the DV context where a similar random token on piece of contact information must be observed). However, for CAA checking I think it makes the most sense to not rely on similarity (particularly with some lookup failures being permission to issue in the CAA context) but instead ensure a sufficient number of network perspectives interpret their lookups as permission to issue. Maybe another approach would be to avoid using the word "corroborate" in the CAA context, but I worry a bit reworking the whole draft with that angle would simply introduce more wording issue.
docs/BR.md
Outdated
| @@ -935,6 +962,8 @@ The CA MAY resend the email, fax, SMS, or postal mail in its entirety, including | |||
|
|
|||
| The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS. | |||
|
|
|||
| CAs using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same IP Address Contact as the Primary Network Perspective. | |||
There was a problem hiding this comment.
I think this triggers MPI on wrong challenge methods for IP addresses?
not sure how one can check RIR documents multiperspectively
think this like is for 3.2.2.5.3 because that's reverse DNS lookup, where multiple perspective make sense.
There was a problem hiding this comment.
Thank you for bringing this up. I agree that putting multi perspective checking in 3.2.2.5.3 makes sens, and it does not make sense here.
To clarify, a potential fix for this would be to remove this paragraph (line 965) that you commented and put something along these lines at the end of 3.2.2.5.3:
CAs using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same token as the FQDN as the Primary Network Perspective.
There was a problem hiding this comment.
3.2.2.5 is looking for domain by rDNS and do verification for that domain be used for that IP address, so matching thing MP need to see be domain name there
There was a problem hiding this comment.
Sorry, I had made a typo in that line recommendation for 3.2.2.5. I meant to delete token and have it read:
CAs using this method MUST implement Multi-Perspective Issuance Corroboration as specified in [Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration). To count as corroborating, a Network Perspective MUST observe the same FQDN as the Primary Network Perspective.
There was a problem hiding this comment.
Addressed in 8f35b32
docs/BR.md
Outdated
|
|
||
| Multi-Perspective Issuance Corroboration attempts to corroborate the determinations (i.e., domain validation pass/fail, CAA permission/prohibition) made by the Primary Network Perspective from multiple additional Network Perspectives before Certificate issuance. This process can improve protection against equally-specific prefix Border Gateway Protocol (BGP) attacks or hijacks. | ||
|
|
||
| The response returned from each corroborating Network Perspective MUST allow the CA to verify: |
There was a problem hiding this comment.
Is it right to consider that CA can't tell remote perspective the token it expected for a validation? from wording of I think it isn't allowed: because hacked remote perspective just repeat token it asked and reply "Yes I saw that token %s you requested there" so reply need to be "I saw "%s" from location %s you request" and actual validity check need to be done on the other side (CA). Am I right? and I'm not sure how to guard CAA from it: do I need to return entire DNSKEY there so it didn't craft there response up?
There was a problem hiding this comment.
I do not think this language should be interpreted that strictly. While this type of behavior (where the remote perspective must prove knowledge of the validation token's value without communication from the primary perspective) potentially offers some security against compromised or misbehaving remote perspectives, I do not think it adds much substantial security, and I feel it adds some unneeded complexity.
On the security side, I largely see attacks where the remote perspectives misbehave (i.e., due to compromise or misconfiguration) outside of the threat model used in this ballot draft. There are currently no other ways for the primary perspective to verify the behavior of the remote perspectives (although the logic running at the primary perspective must enforce that responses from remote perspectives cannot turn a do-not-issue decision into an issue decision).
Furthermore, I do not think not communicating the token to remote perspectives provides a significant security improvement. The adversary in the threat model of this ballot is already aware of the required token that needs to be seen by the remote perspectives. Specifically, if an adversary compromised a remote perspective R and the primary perspective asked "what token did you see for this domain?," it would be trivial for the adversary to craft a response from R claiming it saw the proper token given that this is the very token the adversary was supposed to upload to the victim's webpage. Given the value of the token is already known by the adversary, I don't think there is much security improvement between asking remote perspectives "what token did you see for this domain?" vs "did you see token %s for this domain?" While I do think checking the validity of the token by the primary provides a sanity check that remote perspectives are doing their job, I do not think this check is robust in the case of a compromised remote perspective. @orangepizza you also have a good point about there not being an elegant parallel in the CAA space.
Maybe removing "allow the CA" and "The response returned" could make this language more general:
| The response returned from each corroborating Network Perspective MUST allow the CA to verify: | |
| Each corroborating Network Perspective MUST verify: |
There was a problem hiding this comment.
If I recall correctly, the intent of the existing language was in response to an earlier comment.
The basis for that comment was such that the perspectives should not be obligated to determine whether or not they corroborate the primary (as this would obligate the CA to share the expected token with the perspectives), but instead, perspectives should only be responsible for collecting information and sharing it with the CA. Ultimately, it should be the CA's responsibility to determine whether a perspective corroborates the primary validation.
I think the text should accommodate either implementation approach:
- The CA asks whether the perspective saw $challenge and the perspective responds accordingly ("Did you see '1235ABC1235'"? ---> "Yes.")
- The CA asks the perspective to return the results of the lookup ("What did you see?" ---> "I saw '12345ABC12345'")
@orangepizza / @birgelee - I'll see if I can improve this language further given the above discussion and the original comment.
There was a problem hiding this comment.
Throwing something to wall if it sticks: (not a native speaker)
Either by perspective itself or CA, each corroborating Network Perspective's observation MUST verify:
There was a problem hiding this comment.
I agree with @ryancdickson 's point that the text should accommodate either implementation. Just curious, if we changed it to simply:
Each corroborating Network Perspective's observation MUST verify:
would that clearly permit both interpretations?
Also just to reiterate, in the threat model for MPIC, the adversary is the one requesting a certificate for a domain it does not control and the challenge token is known to the adversary because it is the very token the CA sent to the adversary which was supposed to be uploaded to the domain. Thus, I do not think there is a major security advantage in not sharing tokens with remote perspectives and both of the implementations Ryan Dickson mentioned are good.
There was a problem hiding this comment.
@orangepizza / @birgelee --- thanks for the suggestions.
What about:
"Each corroborating Network Perspective's response MUST provide the CA with the necessary information to allow it to affirmatively assess:
- a. the presence of the expected 1) Random Value, 2) Request Token, 3) IP Address, or 4) Contact Address, as required by the relied upon validation method specified in Sections 3.2.2.4 and 3.2.2.5; and
- b. the CA's authority to issue to the requested domain(s), as specified in Section 3.2.2.8."
There was a problem hiding this comment.
Mocked up in 278f3b8.
|
appendix B (about tor onion names, which can't link as it doens't changed here) assignes few 3.2.2.4 methods over tor network (18/19/20) which this will add MPIC requirement: as it funneled to tor network I'm not sure MVIC is appropriate for onion domains: |
| | 2-5 | 1 | | ||
| | 6+ | 2 | | ||
|
|
||
| Remote Network Perspectives performing Multi-Perspective Issuance Corroboration: |
There was a problem hiding this comment.
I couldn't find rule about where a remote perspective considered to be? Natural answer would be where is the metel it hosted is as this removed no delegation requirement we can't guarantee everything RP does happen at same place. For example HTTP validation RP in JP re‐delegate DNS lookup to public DNS hosted in US and still be legal; but can we say that RP is actually at anywhere?
There was a problem hiding this comment.
The definition of a network perspective's location is with the definition of a "Network Perspective" in the definitions section (line 383). I am curios if you would recommend putting this somewhere else in the document.
Line 383 in 0144a4c
The text on location currently reads:
The location of a Network Perspective is determined by the point where unencapsulated outbound Internet traffic is first handed off to the network infrastructure providing Internet connectivity to that perspective.
In many cases this equates to the definition you mentioned of having the location be where the metal hosting the perspective is. Notably in cases of VPN tunneling, the perspective's location becomes the location where VPN traffic is unencapsulated.
@orangepizza You do have a good point about not everything happening in one place, and I had thought a bit about that DNS angle when coming up with text for this line. Ultimately, I felt the most important attribute of this definition was for it to be well-defined and auditable, and given the fact the DNS is often outsourced, I felt it would be cleaner to define it as where the perspective itself hands off Internet traffic.
I think two points to note when considering this is that:
- the only current diversity requirement in the document references the service regions of different RIRs (essentially continents), so some variance in location between a perspective and its DNS provider will not undermine that diversity
- I personally find it unlikely for performance reasons that a perspective would outsource DNS to another continent. All of the major public DNS resolvers are globally anycast, and other 3rd-party DNS resolvers (e.g., from local ISPs) will also likely be relatively close to the perspective in question. It is usually faster to run DNS resolvers near where queries are originated, and I feel this will help prevent the problem you are discussing. DNS resolvers in other continents can also cause issues with goegraphic load balancing, so distant DNS resolvers are generally not recommended for that reason as well.
It is worth mentioning that at Princeton we have recently made significant advances in tooling to measure the effectiveness of deployed MPIC implementations against real-world ethical BGP attacks. These measurements include measurements of DNS behavior (i.e., we can determine whether a perspective's DNS was fooled by a BGP hijack). I feel that this type of work could shed light on whether outsourced DNS is a real problem for MPIC (in which case maybe a more-specific definition is needed) or if the system generally behaves as expected. In the meantime, I personally like the simpler definition as I do not want compliance and auditability to be obstacles for the MPIC initiative.
There was a problem hiding this comment.
Well, there is another rule(L1060) about network locations: Network Perspectives are considered distinct when the straight-line distance between the two States, Provinces, or Countries they reside in is at least 500 km. and I don't think public resolver should be able to used in MRP context, as for CAA or some challenges like 3.2.2.4.7 or call to contact on DNS challenges DNS lookup is only thing that remote perspective will done, and "public resolver" isn't something really definable: only definition it can have without making actual whitelist will be "any open resolver is public DNS", and allowing that won't end well.
There was a problem hiding this comment.
To clarify, I simply mentioned public DNS resolvers as examples of DNS resolvers. I do not think it makes sense to add any specific text regarding public DNS resolvers.
I see your point that for CAA and some challenges remote perspectives are only sending DNS queries. What about adding text to ensure DNS resolver locations have the same diversity required of network perspectives? Potentially around line 1057
Line 1057 in 0144a4c
I think a statement along these lines could enforce DNS resolver diversity.
A network perspective MAY use a recursive DNS resolver that is not co-located with that network perspective. However, the DNS resolver used by a network perspective MUST fall within the same Regional Internet Registry service region as that network perspective. Furthermore, for any pair of DNS resolvers used on a Multi-Perspective Issuance Corroboration attempt, the straight-line distance between the two States, Provinces, or Countries the DNS resolvers reside in MUST be at least 500 km. The location of a DNS resolver is determined by the point where unencapsulated outbound DNS queries are first handed off to the network infrastructure providing Internet connectivity to that DNS resolver.
There was a problem hiding this comment.
Minor tweaks, addressed in 6cca62b.
|
Also, in response to #8 (comment) , I concur that MPIC is not appropriate for onion domains. Appendix B clearly defines that it is only valid for Version 3 Onion Address and an onion address directly contains the encoded public key of the service you are connecting to (see https://spec.torproject.org/rend-spec/encoding-onion-addresses.html ). This makes you not vulnerable to a BGP hijack over the Tor network and the text prohibiting outsourcing in Appendix B should prevent something like a BGP hijack between the CA and the Tor client. I also see @orangepizza 's point that the current language in Appendix B would require MPIC for onion addresses which does not make sense. Maybe in line 3706 ( Line 3706 in 0144a4c `Even though some methods defined in Section 3.2.2.4 require Multi-Perspective Issuance Corroboration, a CA SHOULD NOT use use Multi-Perspective Issuance Corroboration for the validation of Onion Domain Names. Note: Other than removing the requirement for Multi-Perspective Issuance Corroboration, this section does not override or supersede any provisions specified within the respective methods. The CA MUST only use a method if it is still permitted within that section and MUST NOT issue Wildcard Certificates or use it as an Authorization Domain Name, except as specified by that method.` |
Do not require Onion Domain Names to be validated using MPIC.
Address comments made in cabforum#466
Previously, `va.IsCAAValid` would only check CAA records from the primary VA during initial domain control validation, completely ignoring any configured RVAs. The upcoming [MPIC](ryancdickson/staging#8) ballot will require that it be done from multiple perspectives. With the currently deployed [Multi-Perspective Validation](https://letsencrypt.org/2020/02/19/multi-perspective-validation.html) in staging and production, this change brings us in line with the [proposed phase 3](https://github.com/ryancdickson/staging/pull/8/files#r1368708684). This change reuses the existing [MaxRemoteValidationFailures](https://github.com/letsencrypt/boulder/blob/21fc1912732274d3fc92f3660a8f45d25b2a702c/cmd/boulder-va/main.go#L35) variable for the required non-corroboration quorum. > Phase 3: June 15, 2025 - December 14, 2025 ("CAs MUST implement MPIC in blocking mode*"): > > MUST implement MPIC? Yes > Required quorum?: Minimally, 2 remote perspectives must be used. If using less than 6 remote perspectives, 1 non-corroboration is allowed. If using 6 or more remote perspectives, 2 non-corroborations are allowed. > MUST block issuance if quorum is not met: Yes. > Geographic diversity requirements?: Perspectives must be 500km from 1) the primary perspective and 2) all other perspectives used in the quorum. > > * Note: "Blocking Mode" is a nickname. As opposed to "monitoring mode" (described in the last milestone), CAs MUST NOT issue a certificate if quorum requirements are not met from this point forward. Adds new VA feature flags: * `EnforceMultiCAA` instructs a primary VA to command each of its configured RVAs to perform a CAA recheck. * `MultiCAAFullResults` causes the primary VA to block waiting for all RVA CAA recheck results to arrive. Renamed `va.logRemoteValidationDifferentials` to `va.logRemoteDifferentials` because it can handle initial domain control validations and CAA rechecking with minimal editing. Part of #7061
|
Dear all, Thanks |
|
@romanf However, I will say we have seen some evidence of the adversary evolving its target and CA selection potentially in an attempt to avoid MPIC. This includes picking CAs that do not do MPIC and avoiding properly RPKI-protected prefixes. This also brings me to (what I think is the most important) the point that thwarted attacks is really not the correct metric when considering an attack like this. In some cases like DDoS attacks, the attack is relatively cheap to run and can be difficult to model accurately, thus causing adversaries to "try" the attack to observe the victim's behavior (even if there is a chance of failure). BGP attacks are very different in nature. Each BGP attack poses a risk to the adversary's infrastructure like burning their upstream (i.e., the upstream that propagated the attack discontinuing the adversary's BGP session) as well as other risks (e.g., RADb maintainer accounts getting banned, VPS harddisks getting seized). Thus, for BGP adversaries we often see them launch "test" announcements with prefixes that will not raise alarm to confirm their eventual attack will be successful. There is a good chance that an adversary knowing a CA is doing MPIC and a victim's prefix is protected against global hijacks will never actually attempt this attack. Thus I feel the true value in MPIC is not in the attacks it thwarts but in the attacks it deters. Furthermore, even if an adversary did launch the attack unsuccessfully, it would be nearly indistinguishable from a fat-finger mistake. |
|
Dear Henry, -Roman |
|
Let's Encrypt observes that about 0.25% of failed validations fail specifically due to our remote validation, i.e., our primary perspective completed validation successfully, but two or more of our remote perspectives did not. This number is low enough that it does not represent a burden on us, but high enough that it likely consists mostly of false-negatives (e.g. HTTP-01 validation failing due to different frontends serving a website having different update latency or caching behavior) as opposed to true attacks. |
|
Thanks Aaron for sharing this! |
|
Closing in favor of cabforum#487. |
Summary: This is the latest version of a set of updates that intends to add "Multi-Perspective Domain Validation" and "Multi-Perspective CAA Checking" requirements to the CA/Browser Forum TLS Baseline Requirements.
This Pull Request:
How can you help?:
Version History:
Additional Notes:
Additional Resources:
On MPDV:
On the problem space: