[Servercert-wg] Discussion Period Begins - Ballot SC-067 V2: "Require domain validation and CAA checks to be performed from multiple Network Perspectives"
Chris Clements
cclements at google.com
Mon Jul 1 18:38:34 UTC 2024
Hi Roman, Aaron,
The existing ballot text was intended to offer flexibility to adopters and
was in response to community feedback on earlier drafts of the ballot
(e.g., here
<https://lists.cabforum.org/pipermail/validation/2023-June/001904.html>).
While we agree with your perspective re: simplicity, we equally believe CA
Owners should be able to evaluate and adopt implementations that work best
for them while also achieving the stated security objectives of the ballot.
Thanks
-Chris
On Fri, Jun 28, 2024 at 10:34 AM Aaron Gable via Servercert-wg <
servercert-wg at cabforum.org> wrote:
> Let's Encrypt already implements MPIC, including doing CAA checks from all
> of our perspectives. Obviously our experience is not universal, but we made
> the decision to treat remote CAA checks the exact same as primary ones:
> valid for at most 8 hours. Although this does increase the number of remote
> CAA checks we perform, it keeps us much more confident in our code and
> compliance.
>
> While I understand the motivation behind allowing remote CAA results to be
> cached for an extended period, I personally don't think that the motivation
> is strong enough to actually overcome the extra complications that it
> brings. I would prefer that all remote results have the same lifetimes as
> primary validation data.
>
> Aaron
>
> On Fri, Jun 28, 2024, 01:33 Roman Fischer via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
>> Thanks to both Doug and Chris for these examples.
>>
>>
>>
>> That makes me wonder: Wouldn't it be simpler (and thus less error-prone)
>> to remove the CAA caching and just do the CAA check with each domain
>> validation?
>>
>>
>>
>> Rgds
>> Roman
>>
>>
>>
>> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of
>> *Chris Clements via Servercert-wg
>> *Sent:* Donnerstag, 27. Juni 2024 15:36
>> *To:* Doug Beattie <doug.beattie at globalsign.com>
>> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <
>> servercert-wg at cabforum.org>
>> *Subject:* Re: [Servercert-wg] Discussion Period Begins - Ballot SC-067
>> V2: "Require domain validation and CAA checks to be performed from multiple
>> Network Perspectives"
>>
>>
>>
>> Hi Doug,
>>
>>
>>
>> Working through your examples - and adding one additional, below.
>>
>>
>>
>> Note: these examples strictly assume the to-be-issued certificates only
>> contain the subject dnsName being described (i.e., if www.example.com is
>> the named subject, we do not assume the certificate will also include a
>> dnsName of example.com).
>>
>>
>>
>> - *Day 1: *CA performs MPIC for www.example.com
>>
>>
>> - *Corroborating DCV*: This includes observing a domain validation
>> random token from [N] perspectives, as required by quorum expectations.
>> - *Corroborating CAA*: This includes observing permission to issue
>> when checking CAA from [N] perspectives, as required by quorum expectations.
>>
>>
>>
>> - *Day 100: *A certificate request is made for *shop.example.com
>> <http://shop.example.com/>* from the same applicant
>>
>>
>> - *Corroborating DCV*: This includes observing a domain validation
>> random token from [N] perspectives, as required by quorum expectations.
>> - *Corroborating CAA*: This MAY NOT be skipped given the
>> certificate issued to the customer on Day 1 was for www.example.com
>> and shop.example.com is not a subdomain of www.example.com. The
>> process must be completed as it is described in the “Day 1" example.
>>
>>
>>
>> - *Day 150: *A certificate request is made for x1.www.example.com
>> <http://www.x1.example.com/> from the same applicant
>>
>>
>> - *Corroborating DCV*: This includes observing a domain validation
>> random token from [N] perspectives, as required by quorum expectations.
>> - *Corroborating CAA*: This MAY be skipped given the MPIC CAA
>> event on Day 1 for www.example.com and the described 398-day reuse
>> period because x1.www.example.com is a subdomain of www.example.com
>> .
>>
>>
>>
>> - *Day 400: *A certificate request is made for x2.www.example.com
>> <http://www.x1.example.com/>
>>
>>
>> - *Corroborating DCV*: This includes observing a domain validation
>> random token from [N] perspectives, as required by quorum expectations.
>> - *Corroborating CAA*: Prior reuse cache for www.example.com (Day
>> 1) is now expired. The CA must observe permission to issue when checking
>> CAA from [N] perspectives, as required by quorum expectations.
>>
>>
>>
>> Hopefully this helps clarify, but let us know if you have any questions.
>>
>> -Chris
>>
>>
>> P.S., this response has also been copied to the same doc
>> <https://docs.google.com/document/d/11V43IrkwGbDvL69hxm2smukJfgZH9Qs0md4CPNdbViw/edit>
>> we referenced in response to Christophe in case of any formatting issues
>> conveyed through the list.
>>
>>
>>
>> On Tue, Jun 25, 2024 at 2:17 PM Doug Beattie <doug.beattie at globalsign.com>
>> wrote:
>>
>> Hi Chris,
>>
>>
>>
>> I was taking a closer look at the ballot and specifically this section on
>> caching the remote node CAA checks:
>>
>>
>>
>> A CA MAY reuse corroborating evidence for CAA record quorum compliance
>> for a maximum of 398 days. After issuing a Certificate to a domain, remote
>> Network Perspectives MAY omit retrieving and processing CAA records for the
>> same domain or its *subdomains *in subsequent Certificate requests from
>> the same Applicant for up to a maximum of 398 days.
>>
>>
>>
>> I think understand the first sentence – if you do a full check on a FQDN
>> (the value that you will put into the SAN field), then you only need to do
>> the normal CAA check for that FQDN from the primary node for 398 days.
>>
>>
>>
>> I don’t understand the references to domain and subdomains in the second
>> sentence. Can you explain how this should work?
>>
>> - You do a full MIC check on www.example.com on day 1
>> - You find CAA records with permission to issue on example.com on
>> primary and remote nodes so you issue
>> - Day 100, customer wants to issue to shop.example.com
>>
>>
>> - This is a subdomain of example.com where we found the records
>> permitting issuance on day 1.
>> - What checks do we need to do for this request?
>>
>>
>> - Day 150, Applicant wants to issue to x1.www.example.com (a
>> subdomain of www.example.com we issued on day 1):
>>
>>
>> - What checks would be required here?
>>
>>
>>
>> Maybe I’m reading too much into this…
>>
>>
>>
>> Thanks!
>>
>>
>>
>> Doug
>>
>>
>>
>> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of
>> *Chris Clements via Servercert-wg
>> *Sent:* Friday, April 26, 2024 1:01 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 V2:
>> "Require domain validation and CAA checks to be performed from multiple
>> Network Perspectives"
>>
>>
>>
>> *Purpose of Ballot SC-067 V2*:
>>
>>
>>
>> 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).
>>
>>
>>
>> *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
>>
>>
>>
>> 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..5224983ef0a6f94c18808ea3469e7a5ae35746e5
>>
>>
>>
>> *— Motion Ends —*
>>
>>
>>
>> This ballot proposes a Final Maintenance Guideline. The procedure for
>> approval of this ballot is as follows:
>>
>>
>>
>> *Discussion (at least 14 days)*
>>
>> - Start: 2024-04-26 17:00:00 UTC
>>
>> - End no earlier than: 2024-05-10 17:00: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/20240701/1c299374/attachment-0001.html>
More information about the Servercert-wg
mailing list