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

Wed Jun 5 14:58:37 UTC 2024

I was not aware of this effort and I'm trying to find any relevant 
emails to the group that I missed with any of these announcements.

In any case, thank you for the update, I'm sure this will receive more 
attention (and contributions) now that it has been highlighted :)

Dimitris.

On 4/6/2024 11:51 μ.μ., Ryan Dickson via Servercert-wg wrote:
>
> 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 
> <https://github.com/cabforum/servercert/pull/487>
>
> [2] https://github.com/open-mpic/open-mpic-specification 
> <https://github.com/open-mpic/open-mpic-specification>
>
> [3] 
> https://docs.google.com/document/d/19wvjk7lcK1TCQpJrjEljosTEe8A0We1ayRp_1Ou3r4s/edit#heading=h.9kf5j5tsn6i7 
> <https://docs.google.com/document/d/19wvjk7lcK1TCQpJrjEljosTEe8A0We1ayRp_1Ou3r4s/edit#heading=h.9kf5j5tsn6i7>
>
> [4] 
> https://github.com/cabforum/servercert/pull/487#discussion_r1557725687 
> <https://github.com/cabforum/servercert/pull/487#discussion_r1557725687>
>
> [5] 
> https://github.com/cabforum/servercert/pull/507/commits/01b3f1d9fa361d0dc568cf5a2713e6f39abb7438#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR389 
> <https://github.com/cabforum/servercert/pull/507/commits/01b3f1d9fa361d0dc568cf5a2713e6f39abb7438#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR389>
>
> [6] 
> https://drive.google.com/file/d/1LTwtAwHXcSaPVSsqKQztNJrV2ozHJ7ZL/view 
> <https://drive.google.com/file/d/1LTwtAwHXcSaPVSsqKQztNJrV2ozHJ7ZL/view>
>
> [7] 
> https://archive.cabforum.org/pipermail/servercert-wg/2024-April/004411.html 
> <https://archive.cabforum.org/pipermail/servercert-wg/2024-April/004411.html>
>
> [8] 
> https://archive.cabforum.org/pipermail/servercert-wg/2024-April/004417.html 
> <https://archive.cabforum.org/pipermail/servercert-wg/2024-April/004417.html>
>
> [9] 
> https://archive.cabforum.org/pipermail/servercert-wg/2024-May/004614.html 
> <https://archive.cabforum.org/pipermail/servercert-wg/2024-May/004614.html>
>
> [10] 
> https://github.com/cabforum/servercert/pull/517/files#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1110 
> <https://github.com/cabforum/servercert/pull/517/files#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1110>
>
> [11] https://lists.princeton.edu/cgi-bin/wa?A0=OPEN-MPIC 
> <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/
>     <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
>     <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
>     <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
>     <https://medium.com/s2wblog/post-mortem-of-klayswap-incident-through-bgp-hijacking-en-3ed7e33de600>
>
>     [4] https://www.coinbase.com/blog/celer-bridge-incident-analysis
>     <https://www.coinbase.com/blog/celer-bridge-incident-analysis>
>
>     [5]
>     https://www.usenix.org/conference/usenixsecurity23/presentation/cimaszewski
>     <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
>     <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
>     <https://www.usenix.org/conference/usenixsecurity21/presentation/birge-lee>
>
>     [8]
>     https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee
>     <https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee>
>
>     [9]
>     https://security.googleblog.com/2023/05/google-trust-services-acme-api_0503894189.html
>     <https://security.googleblog.com/2023/05/google-trust-services-acme-api_0503894189.html>
>
>     [10] https://github.com/ryancdickson/staging/pull/6
>     <https://github.com/ryancdickson/staging/pull/6>
>
>     [11] https://github.com/ryancdickson/staging/pull/8
>     <https://github.com/ryancdickson/staging/pull/8>
>
>     [12] https://github.com/cabforum/servercert/pull/487
>     <https://github.com/cabforum/servercert/pull/487>
>
>     [13]
>     https://github.com/cabforum/servercert/compare/6d10abda8980c6eb941987d3fc26e753e62858c0..5224983ef0a6f94c18808ea3469e7a5ae35746e5
>     <https://github.com/cabforum/servercert/compare/6d10abda8980c6eb941987d3fc26e753e62858c0..5224983ef0a6f94c18808ea3469e7a5ae35746e5>
>
>     [14] https://github.com/cabforum/servercert/pull/507
>     <https://github.com/cabforum/servercert/pull/507>
>
>     [15]
>     https://github.com/cabforum/servercert/compare/5224983ef0a6f94c18808ea3469e7a5ae35746e5..2dcf1a8fe5fc7b6a864b5767ab1db718bc447463
>     <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
>     <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
>
>
> _______________________________________________
> 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/20240605/deee6774/attachment-0001.html>