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
<[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/
<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]> *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]>
*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
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
_______________________________________________
Servercert-wg mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
_______________________________________________
Servercert-wg mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
