[Servercert-wg] Discussion Period Begins - Ballot SC-067 V3: "Require domain validation and CAA checks to be performed from multiple Network Perspectives"

Tue Jun 4 20:50:00 UTC 2024

Hi Roman,

Thank you for highlighting the Princeton Open MPIC Project, which we
introduced in the preamble of SC-067 Version 1 [1]. While we appreciate
your (and others) perspective, this ballot intends to close an open
vulnerability that was presented at F2F 58 (February 28, 2023), and as I
understand it, discussed within the Server Certificate Working Group before
that time.

There are multiple approaches to implementing MPIC in a manner that
satisfies the requirements described in this ballot. The Princeton API [2]
is just one example. We also see an API [3] available from Cloudflare, and
earlier ballot discussion highlighted VPNs [4] could also be used in lieu
of standing up remote cloud server instances. The ballot was subsequently
updated [5] to make the permitted use of VPNs clear.

Beyond this, I’m unaware of other ballots passed in recent history that
have gone to such lengths to ensure ease of community adoption, especially
ones intended at introducing meaningful security improvements in response
to a demonstrated and ongoing vulnerability. This approach has included
delaying the Effective Dates described in earlier proposals [6, slide 37],
and also adopting a phased approach that strengthens over time to allow CA
Owners a reasonable amount of flexibility and time for them to fine-tune
implementations before blocking action becomes normative [6, slide 38].

Just as was discussed in messages [7][8][9] related to third-party linting
tools, delaying the adoption of an important security function because of a
dependency on a voluntary contribution by a third-party who is not a Forum
participant is a path that must be avoided.

Regardless of the above, we’ve checked with the Princeton researchers and
they have indicated:

   -

   they expect the current API specification [2] to be implemented by
   September 2024. The ballot describes the first “MUST" implementation date
   as March 15, 2025 [10]. I’ll note this “MUST" effective date is
   intentionally “soft”, as CAs can use their discretion as to whether MPIC
   responses block issuance. The “hard" block requirement takes effect
   September 15, 2025.
   -

   they are expected to upload a functional prototype to GitHub this week.
   -

   only 4 CA Owners have joined the Open MPIC Project mailing list [11].

Related to the Open MPIC Project mailing list, I was surprised at such low
participation and interest in collaboration given (1) the perceived
community reaction to Henry’s presentation at F2F 58 and following
discussions and (2) how long we’ve been discussing MPIC within the
Validation Subcommittee and broader SCWG. Beyond the points earlier about
the risk and precedent of delaying adoption of a security function as a
result of a voluntary third-party contribution, it’s difficult to reason
this limited community participation as a motivating factor for delaying
the ballot, which should be instead interpreted as helping close an open
Web PKI vulnerability, as a result of the project’s progress.

Thanks,

Ryan

References:

[1] https://github.com/cabforum/servercert/pull/487

[2] https://github.com/open-mpic/open-mpic-specification

[3]
https://docs.google.com/document/d/19wvjk7lcK1TCQpJrjEljosTEe8A0We1ayRp_1Ou3r4s/edit#heading=h.9kf5j5tsn6i7

[4] https://github.com/cabforum/servercert/pull/487#discussion_r1557725687

[5]
https://github.com/cabforum/servercert/pull/507/commits/01b3f1d9fa361d0dc568cf5a2713e6f39abb7438#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR389

[6] https://drive.google.com/file/d/1LTwtAwHXcSaPVSsqKQztNJrV2ozHJ7ZL/view

[7]
https://archive.cabforum.org/pipermail/servercert-wg/2024-April/004411.html

[8]
https://archive.cabforum.org/pipermail/servercert-wg/2024-April/004417.html

[9]
https://archive.cabforum.org/pipermail/servercert-wg/2024-May/004614.html

[10]
https://github.com/cabforum/servercert/pull/517/files#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1110

[11] https://lists.princeton.edu/cgi-bin/wa?A0=OPEN-MPIC

On Tue, Jun 4, 2024 at 3:47 AM Roman Fischer via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Dear all,
>
>
>
> I was informed by direct mail about the following which I find very
> interesting and wanted to share here:
>
>
>
> Princeton researchers are working on an open source implementation of MPIC
> and are looking for collaborators:
> https://freedom-to-tinker.com/2024/02/13/announcing-the-open-multi-perspective-issuance-corroboration-project/.
> The first version of the API specification is on github
> <https://github.com/open-mpic/open-mpic-specification/tree/main>.
>
>
>
> As these developments seem to be in an early stage, wouldn’t it make sense
> to postpone this ballot until at least a first draft of this open source
> implementation is available? I don’t think it makes sense that each CA
> invents their own protocols and possibly makes avoidable mistakes coding /
> implementing this non-trivial topic..
>
>
>
> Kind regards
> Roman
>
>
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of *Chris
> Clements via Servercert-wg
> *Sent:* Montag, 20. Mai 2024 16:30
> *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/20240604/512f75f9/attachment-0001.html>