Hi Roman, I think it’s because these developments are at an early stage (amongst other reasons) that it doesn’t make sense to postpone the ballot. I don’t see anything super concrete indicating that this project will alter the industry’s approach to MPIC adoption, and I believe something pretty substantive would be necessary in order for it to make sense to adopt this external project as a dependency for updating policy requirements in the TBRs.
Cheers, -Clint > On Jun 4, 2024, at 12:47 AM, Roman Fischer via Servercert-wg > <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 > <[email protected] <mailto:[email protected]>> > 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 > [email protected] <mailto:[email protected]> > https://lists.cabforum.org/mailman/listinfo/servercert-wg
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Servercert-wg mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/servercert-wg
