[Servercert-wg] Discussion Period Begins - Ballot SC-067 V3: "Require domain validation and CAA checks to be performed from multiple Network Perspectives"
Ryan Dickson
ryandickson at google.com
Thu May 30 18:44:49 UTC 2024
Hi Christophe,
Answers to your questions are listed below, flagged with a “CRP Response"
prefix.
Due to expected formatting and readability issues commonly observed with
the mail archive (i.e., poorly formatted bulleted lists), a copy of this
content is available in doc form here
<https://docs.google.com/document/d/11V43IrkwGbDvL69hxm2smukJfgZH9Qs0md4CPNdbViw/edit>.
The doc copy is only intended to improve readability.
Case 1: DNS TXT with correct expected TXT value but different other TXT
values present on remote perspective
Suppose the following responses from:
-
Primary perspective: TXT with 2 records: a=1; c=2
-
Remote perspective: TXT with 2 records: a=1; c=3
If the expected random value is a=1, is the corroboration limited to only
the “a” TXT record, and not impacted by a difference to the “c” record?
Our understanding is yes due to the statement “can corroborate the outcomes
determined by the Primary Network Perspective”, where that outcome would be
“was the primary perspective able to retrieve a TXT record a=1”.
CRP Response: Yes, your understanding is correct. The observation of c=3
from the remote perspective has no bearing on the corroboration of a=1.
Case 2: DNS TXT with corroboration between remote perspectives only
Suppose the following responses from:
-
Primary perspective: no TXT records
-
Remote perspective 1: TXT with expected value
-
Remote perspective 2: TXT with expected value
Suppose the # of allowed non-corroborations is 1 (the primary perspective
being the non-corroborating instance). Is our understanding correct that
“corroboration” is intended to confirm the value of the primary
perspective, meaning that if there was no success obtaining the value on
the primary perspective, it can not be corroborated? This is based on the
statement “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.”
Or is the intention to consider the 3 nodes as the quorum and since remote
perspective 1 and 2 corroborate, the expected value is verified
successfully? In other words, is the quorum including all network
perspectives, including the primary, or only the remote perspectives?
CRP Response: MPIC intends to corroborate the Primary Network Perspective
through the use of additional remote network perspectives. The primary
perspective shall not be considered part of the quorum. If the primary
perspective does not observe a TXT record when it’s otherwise expected, the
obligations of 3.2.2.4.7 have not been met and it would be impossible for
MPIC to succeed because there is nothing to corroborate. Please remember,
MPIC only presents the opportunity to block issuance, it is not considered
authoritative for domain authorization or control. If the primary lookup
fails, there is no expectation to perform MPIC as it cannot succeed.
Case 3: CAA returns valid but different Issuer Domain Names from different
subdomains
Suppose the following responses from:
-
Primary perspective: a.b.c.domain.com returns ca.com for CAA
-
Remote perspective 1: b.c.domain.com returns ca.net for CAA
And both ca.com and ca.net are defined by the CA as Issuer Domain Names.
Is the intention of corroboration to only confirm if all network
perspectives return a “permission to issue”? Would corroboration also
require the contents of the CAA values to match (so ca.com and ca.net would
not corroborate)? Would the difference in path building (primary
perspective obtains the result from a.b.c, remote perspective obtains from
b.c) result in a non-corroboration result? The statement “regardless of
whether the responses from both Perspectives are byte-for-byte identical.”
Seems to hint at the contents of the CAA values, but maybe this is not
intentional.
CRP Response: To count as corroborating, it is not necessary for the CAA
records to match exactly. In your example, we would consider the remote
perspective to corroborate the primary perspective’s permission to issue
(as in, both the primary and remote network perspectives agree that the CA
is permitted to issue). Even though the checks found CAA records at
different subdomains and distinct values, each of these CAA record checks
yields “permission to issue = true” and only the boolean results of the
different checks need to be compared using the quorum policy. Checking in
this manner avoids potential false positives related to benign DNS
discrepancies.
Exploring other MPIC CAA evaluation scenarios for added clarity and
completeness:
Note: In all of the following scenarios, assume there is no available
re-use data (e.g., afforded by line 1072
<https://github.com/cabforum/servercert/compare/c4a34fe2292022e0a04ba66b5a85df75907ac2a2..2dcf1a8fe5fc7b6a864b5767ab1db718bc447463#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1072>of
the compare).
Scenario A:
-
Domain to be evaluated: a.b.c.domain.com
-
Primary perspective: Look up for a.b.c.domain.com returns [ca.com] for
CAA
-
Remote perspective 1:
-
Look up for a.b.c.domain.com returns [NO CAA RECORD], walk the tree
-
Look up for b.c.domain.com returns [NO CAA RECORD], walk the tree
-
Look up for c.domain.com returns [NO CAA RECORD], walk the tree
-
Look up for domain.com returns [NO CAA RECORD], walk the tree
-
Look up for com returns [NO CAA RECORD]
-
[Evaluation process completed]
-
Outcome: The remote perspective is interpreted as permitting issuance.
It counts as corroborating.
Scenario B:
-
Domain to be evaluated: a.b.c.domain.com
-
Primary perspective: Look up for a.b.c.domain.com returns [ca.com] for
CAA
-
Remote perspective 1:
-
Look up for a.b.c.domain.com returns [NO CAA RECORD], walk the tree
-
Look up for b.c.domain.com returns [ca.com] for CAA
-
[Evaluation process completed]
-
Outcome: The remote perspective is interpreted as permitting issuance.
It counts as corroborating.
Scenario C:
-
Domain to be evaluated: a.b.c.domain.com
-
Primary perspective: Look up for a.b.c.domain.com returns [ca.com] for
CAA
-
Remote perspective 1:
-
Look up for a.b.c.domain.com returns [NO CAA RECORD], walk the tree
-
Look up for b.c.domain.com returns [ca.net] for CAA
-
[Evaluation process completed]
-
Outcome: The remote perspective is interpreted as permitting issuance.
It counts as corroborating.
Scenario D:
-
Domain to be evaluated: a.b.c.domain.com
-
Primary perspective: Look up for a.b.c.domain.com returns [ca.com] for
CAA
-
Remote perspective 1:
-
Look up for a.b.c.domain.com returns [xyz.tld] for CAA
-
[Evaluation process completed]
-
Outcome: The remote perspective is interpreted as NOT permitting
issuance. It DOES NOT count as corroborating.
Scenario E:
-
Domain to be evaluated: a.b.c.domain.com
-
Primary perspective: Look up for a.b.c.domain.com returns ca.com for CAA
-
Remote perspective 1:
-
Look up for a.b.c.domain.com returns [NO CAA RECORD], walk the tree
-
Look up for b.c.domain.com returns xyz.tld for CAA
-
[Evaluation process completed]
-
Outcome: The remote perspective is interpreted as NOT permitting
issuance. It DOES NOT count as corroborating.
Hope this helps!
- Ryan
On Thu, May 30, 2024 at 5:55 AM Christophe Bonjean via Servercert-wg <
servercert-wg at cabforum.org> wrote:
> Hi Chris, all,
>
>
>
> I’d like to discuss a few interpretations related to the scope of
> corroboration.
>
>
>
> *Case 1: DNS TXT with correct expected TXT value but different other TXT
> values present on remote perspective*
>
> Suppose the following responses from:
>
> - Primary perspective: TXT with 2 records: a=1; c=2
> - Remote perspective: TXT with 2 records: a=1; c=3
>
>
>
> If the expected random value is a=1, is the corroboration limited to only
> the “a” TXT record, and not impacted by a difference to the “c” record?
>
>
>
> Our understanding is yes due to the statement “can corroborate the
> outcomes determined by the Primary Network Perspective”, where that outcome
> would be “was the primary perspective able to retrieve a TXT record a=1”.
>
>
>
> *Case 2: DNS TXT with corroboration between remote perspectives only*
>
> Suppose the following responses from:
>
> - Primary perspective: no TXT records
> - Remote perspective 1: TXT with expected value
> - Remote perspective 2: TXT with expected value
>
>
>
> Suppose the # of allowed non-corroborations is 1 (the primary perspective
> being the non-corroborating instance). Is our understanding correct that
> “corroboration” is intended to *confirm* the value of the primary
> perspective, meaning that if there was no success obtaining the value on
> the primary perspective, it can not be corroborated? This is based on the
> statement “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.”
>
>
>
> Or is the intention to consider the 3 nodes as the quorum and since remote
> perspective 1 and 2 corroborate, the expected value is verified
> successfully? In other words, is the quorum including all network
> perspectives, including the primary, or only the remote perspectives?
>
>
>
> *Case 3: CAA returns valid but different Issuer Domain Names from
> different subdomains*
>
> Suppose the following responses from:
>
> - Primary perspective: a.b.c.domain.com returns ca.com for CAA
> - Remote perspective 1: b.c.domain.com returns ca.net for CAA
>
>
>
> And both ca.com and ca.net are defined by the CA as Issuer Domain Names.
>
>
>
> Is the intention of corroboration to only confirm if all network
> perspectives return a “permission to issue”? Would corroboration also
> require the contents of the CAA values to match (so ca.com and ca.net
> would not corroborate)? Would the difference in path building (primary
> perspective obtains the result from a.b.c, remote perspective obtains from
> b.c) result in a non-corroboration result? The statement “regardless of
> whether the responses from both Perspectives are byte-for-byte identical.”
> Seems to hint at the contents of the CAA values, but maybe this is not
> intentional.
>
>
>
> Christophe
>
>
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of *Chris
> Clements via Servercert-wg
> *Sent:* Monday, May 20, 2024 4:30 PM
> *To:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg at cabforum.org>
> *Subject:* [Servercert-wg] Discussion Period Begins - Ballot SC-067 V3:
> "Require domain validation and CAA checks to be performed from multiple
> Network Perspectives"
>
>
>
> *Purpose of Ballot SC-067 V3*:
>
>
>
> This Ballot proposes updates to the *Baseline Requirements for the
> Issuance and Management of Publicly-Trusted TLS Server Certificates*
> (i.e., TLS BRs) related to “Multi-Perspective Issuance Corroboration”
> (“MPIC”).
>
>
>
> *Background*:
>
>
>
> - MPIC refers to performing domain validation and CAA checks from multiple
> Network Perspectives before certificate issuance, as described within the
> Ballot for the applicable validation methods in TLS BR Sections 3.2.2.4 and
> 3.2.2.5.
>
> - Not all methods described in TLS BR Sections 3.2.2.4 and 3.2.2.5 will
> require using MPIC.
>
> - This work was most recently motivated by research presented at
> Face-to-Face 58 [1] by Princeton University, but has been discussed for
> years prior as well.
>
> - The goal of this proposal is to make it more difficult for adversaries
> to successfully launch equally-specific prefix attacks against the domain
> validation processes described in the TLS BRs.
>
> - Additional background information can be found in an update shared at
> Face-to-Face 60 [2].
>
>
>
> *Benefits of Adoption*:
>
>
>
> - Recent publicly-documented attacks have used BGP hijacks to fool domain
> control validation and obtain malicious certificates, which led to the
> impersonation of HTTPS websites [3][4].
>
> - Routing security defenses (e.g., RPKI) can mitigate the risk of global
> BGP attacks, but localized, equally-specific BGP attacks still pose a
> significant threat to the Web PKI [5][6].
>
> - Corroborating domain control validation checks from multiple network
> perspectives (i.e., MPIC) spread across the Internet substantially reduces
> the threat posed by equally-specific BGP attacks, ensuring the integrity of
> domain validation and issuance decisions [5][7][8].
>
> - Existing deployments of MPIC at the scale of millions of certificates a
> day demonstrate the feasibility of this technique at Internet scale [7][9].
>
>
>
> *Intellectual Property (IP) Disclosure*:
>
>
>
> - While not a Server Certificate Working Group Member, researchers from
> Princeton University presented at Face-to-Face 58, provided academic
> expertise, and highlighted publicly-available peer-reviewed research to
> support Members in drafting this ballot.
>
> - The Princeton University researchers indicate that they have not filed
> for any patents relating to their MPIC work and do not plan to do so in the
> future.
>
> - Princeton University has indicated that it is unable to agree to the
> CA/Browser Forum IPR agreement because it could encumber inventions
> invented by researchers not involved in the development of MPIC or with the
> CA/B Forum.
>
> - Princeton University has instead provided the attached IPR statement.
> Pursuant to the IPR statement, Princeton University has granted a worldwide
> royalty free license to the intellectual property in MPIC developed by the
> researchers and has made representations regarding its lack of knowledge of
> any other Princeton intellectual property needed to implement MPIC.
>
> - The attached IPR statement has not changed since disclosed in Discussion
> Round 1.
>
> - For clarity, Princeton University’s IPR statement is NOT intended to
> replace the Forum’s IPR agreement or allow Princeton to participate in the
> Forum in any capacity.
>
> - Members seeking legal advice regarding this ballot should consult their
> own counsel.
>
>
>
> *Proposal Revision History*:
>
>
>
> - Pre-Ballot Release #1 (work team artifacts and broader Validation
> Subcommittee collaboration) [10]
>
> - Pre-Ballot Release #2 [11]
>
>
>
> *Previous versions of this Ballot*:
>
> - Ballot Release #1 [12] (comparing Version 2 to Version 1) [13]. Note,
> some of the changes represented in the comparison are updates made by other
> ballots that have since passed (e.g., SC-069).
>
> - Ballot Release #2 [14] (comparing Version 3 to Version 2) [15]. Note,
> some of the changes represented in the comparison are updates made by other
> ballots that have since passed (e.g., SC-072).
>
>
>
> *References*:
>
> [1]
> https://cabforum.org/wp-content/uploads/13-CAB-Forum-face-to-face-multiple-vantage-points.pdf
>
> [2]
> https://drive.google.com/file/d/1LTwtAwHXcSaPVSsqKQztNJrV2ozHJ7ZL/view?usp=drive_link
>
>
> [3]
> https://medium.com/s2wblog/post-mortem-of-klayswap-incident-through-bgp-hijacking-en-3ed7e33de600
>
>
> [4] https://www.coinbase.com/blog/celer-bridge-incident-analysis
>
> [5]
> https://www.usenix.org/conference/usenixsecurity23/presentation/cimaszewski
>
>
> [6]
> https://www.blackhat.com/docs/us-15/materials/us-15-Gavrichenkov-Breaking-HTTPS-With-BGP-Hijacking-wp.pdf
>
>
> [7]
> https://www.usenix.org/conference/usenixsecurity21/presentation/birge-lee
>
> [8]
> https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee
>
> [9]
> https://security.googleblog.com/2023/05/google-trust-services-acme-api_0503894189.html
>
>
> [10] https://github.com/ryancdickson/staging/pull/6
>
> [11] https://github.com/ryancdickson/staging/pull/8
>
> [12] https://github.com/cabforum/servercert/pull/487
>
> [13]
> https://github.com/cabforum/servercert/compare/6d10abda8980c6eb941987d3fc26e753e62858c0..5224983ef0a6f94c18808ea3469e7a5ae35746e5
>
> [14] https://github.com/cabforum/servercert/pull/507
>
> [15]
> https://github.com/cabforum/servercert/compare/5224983ef0a6f94c18808ea3469e7a5ae35746e5..2dcf1a8fe5fc7b6a864b5767ab1db718bc447463
>
>
>
>
> The following motion has been proposed by Chris Clements and Ryan Dickson
> of Google (Chrome Root Program) and endorsed by Aaron Gable (ISRG / Let’s
> Encrypt) and Wayne Thayer (Fastly).
>
>
>
> *— Motion Begins —*
>
>
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted TLS Server Certificates” (“Baseline
> Requirements”), based on Version 2.0.4.
>
>
>
> MODIFY the Baseline Requirements as specified in the following Redline:
>
>
> https://github.com/cabforum/servercert/compare/c4a34fe2292022e0a04ba66b5a85df75907ac2a2..2dcf1a8fe5fc7b6a864b5767ab1db718bc447463
>
>
>
>
> *— Motion Ends —*
>
>
>
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
>
>
>
> *Discussion (at least 11 days)*
>
> - Start: 2024-05-20 14:30:00 UTC
>
> - End no earlier than: 2024-05-31 14:30:00 UTC
>
>
>
> *Vote for approval (7 days)*
>
> - Start: TBD
>
> - End: TBD
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240530/7826277e/attachment-0001.html>
More information about the Servercert-wg
mailing list