Here are the minutes for the 2024-08-22 meeting of the validation-sc, as recorded by Ryan Dickson and approved at the 2024-09-05 meeting.
Minutes of the Validation Subcommittee Meeting on 2024-08-22 Attendees: Aaron Gable (Let's Encrypt), Aaron Poulsen (Amazon), Abhishek Bhat (eMudhra), Andrea Holland (VikingCloud), Aneta Wojtczak-Iwanicka (Microsoft), Ben Wilson (Mozilla), Chris Clements (Google), Clint Wilson (Apple), Corey Bonnell (DigiCert), Corey Rasmussen (OATI), Dimitris Zacharopoulos (HARICA), Dustin Hollenback (Microsoft), Enrico Entschew (D-TRUST), Gurleen Grewal (Google), Jaime Hablutzel (OISTE Foundation), Janet Hines (VikingCloud), Johnny Reading (GoDaddy), Kiran Tummala (Microsoft), Li-Chun Chen (Chunghwa Telecom), Mads Henriksveen (Buypass AS), Mahua Chaudhuri (Microsoft), Michael Slaughter (Amazon), Michelle Coon (OATI), Nargis Mannan (VikingCloud), Paul van Brouwershaven (Entrust), Rebecca Kelly (SSL.com), Rollin Yu (TrustAsia), Ryan Dickson (Google), Scott Rea (eMudhra), Stephen Davidson (DigiCert), Sven Rajala (Keyfactor), Tobias Josefowitz (Opera Software AS), Trevoli Ponds-White (Amazon), Wayne Thayer (Fastly), Wendy Brown (US Federal PKI Management Authority) Meeting Kickoff: * Corey greeted participants and noted recording has started * Ryan will take minutes * Corey read the note-well * Corey read the participants list (above) * The August 8, 2024 meeting minutes were approved due to no objections. * Question on minutes from Aaron: The participants list generated by the member tool wasn’t accurate after the meeting ended. Corey mentioned forcing the refresh is a good standard practice, but it’s not clear why the force refresh is needed. Dimitris encouraged Aaron to follow up with the Infrastructure WG or with Martijn directly. Scott also indicated similar issues in the past. Aaron also noticed refreshing changed the formatting of the list (hyphens removed). Wayne also volunteered to take note and raise with the Infrastructure WG during the next call. * Corey reviewed the Agenda, no updates. Discussion and reminder for call for endorsers on Organization Name alignment ballot ( <https://lists.cabforum.org/pipermail/validation/2024-August/002006.html> https://lists.cabforum.org/pipermail/validation/2024-August/002006.html) * Martijn is seeking endorsers for the proposal, however was unable to join the call. If interested in endorsing, message Martijn or the list. * No further discussion. Discussion on language improvements for cPSUri and CRLDP ( <https://lists.cabforum.org/pipermail/validation/2024-August/002009.html> https://lists.cabforum.org/pipermail/validation/2024-August/002009.html) * Corey highlighted the thread and Pull Request where changes were being proposed and discussed. * Corey mentioned some discussion on GitHub is ongoing focusing on defining the term “scheme.” * Use of “URI Scheme" appears to have general consensus from many members on the call (including Clint, Corey, and Dimitris). Enrico will work on creating updated language. * Next steps would be for the proposal to transition into the Server Certificate Working Group, Enrico agreed and will take action. Discussion on language improvements for EV Registration Number ( <https://lists.cabforum.org/pipermail/validation/2024-August/002008.html> https://lists.cabforum.org/pipermail/validation/2024-August/002008.html) * Corey discussed recent feedback on the thread from Clint, and that the idea might require a forward-looking effective date. * Clint indicated consistent formatting of an attribute being included in Subject DNs would be helpful. A short effective date to require the recommended format appears to be a good middle ground. * Corey indicated he’d iterate and contemplate an effective date 3-6 months into the future. * Wayne re-visited the idea of having a lint available to accompany a potential future ballot. * Aaron offered a summary of past discussion (lints not required, but encouraged to accompany a ballot that updates profiles). * Wayne suggested as part of the future effective date, we should contemplate how long it might take to write a lint. * Corey also highlighted challenges with creating a lint that accurately detects potential mis-issuance. More investigation is required. * Dimitris shared a reminder that in the past there were discussions within the SCWG that offered potential improvement for more consistent methods of identifying organizations. Perhaps if pursued, those ideas could solve the challenge being addressed by this proposal. * Corey indicated this ballot arose out of an incident that appeared to be due to a misinterpretation of the existing language. He agreed the group should have a broader conversation on how to handle Organization ID moving forward. Threat modeling DNS-based domain validation (method #7) using the STRIDE model ( <https://en.wikipedia.org/wiki/STRIDE_model> https://en.wikipedia.org/wiki/STRIDE_model) * On previous calls, various participants had different ideas on what was permitted during the DCV process. There also appeared to exist assumptions that were not universally shared. * Through the STRIDE exercise, the goal is to establish a common understanding and perspective. * The main reason for STRIDE is that it was used successfully in the past within the subcommittee. * There was some discussion on whether STRIDE was most appropriate, but no further discussion on list about a better threat modeling framework that might be better suited for the group. * No comments or objections related to using STRIDE, the group will proceed with this model. * Corey highlighted the existence of a video previously shared by Trev in NetSec that summarized STRIDE and how to sequence steps of the analysis. * High-level steps: * Step 1: Model the system (components and interactions between components) * Challenge: We’ll need to come up with a model that’s applicable to all CAs, despite possible differences between them. * Step 2: Come up with list of attacks on the system * Step 3: Come up with list of mitigations * The group discussed the best approach for operationalizing the framework. * Slaughter supported use of a Google Doc * Corey suggested we create a blank doc and make the URL accessible on the Wiki * We started using the model * Slaughter asked what we should consider the scope. Corey suggested strictly Method 7. Dimitris indicated we aren’t questioning the underlying security properties of DNS, in general. * Corey suggested the scope should be a system that performs Method 7, and study the interactions of the components of that system. At that point, we can identify interactions and define them as in or out of scope. * Tobi indicated the challenge is the DNS protocol itself and how it’s used by resolvers, and the idea of outsourcing the core functionality of what a CA has to provide before issuing certificates. In his opinion, this doesn’t translate into what the STRIDE model describes. He does not believe the framework will be useful. * The group briefly debated the value of the STRIDE model. * Tobi: Whatever part of the system actually makes the requests to the authoritative name server of the domains in question — that are used to determine if validation has passed or not — in the proposal from Google Trust Services, that could be a third-party resolver — and in my perspective, that can only be a name server or some other implementation on the CA side. No other part of the system factors into it. * Slaughter: Scoping - you want to scope this to when the CA creates a DNS query to something? * Tobi: There are two distinct DNS protocols. They have the same name, they use the same packet format, but they are different. One is for requests to authoritative name servers and those responses. The other is for requests to resolvers. Some people here are suggesting that a CA could make a request to the resolver, the resolver does all the work, give you a single response back, and the CA would make a determination on the response. This is a different version of the protocol than the one used to talk to authoritative name servers. My concern is primarily in the addition of the DNS protocol spoken between authoritative name servers and resolvers. That is where I see the problem that in my opinion makes it not a viable option to use 3rd parties for DNS resolution in domain validation. If anyone wants to model anything in response to my concern, I don’t think STRIDE is a useful model. * Dimitris: I agree with Tobi, we should not allow delegated resolvers. This model will help us prove that. Maybe along the way we’ll find other threats that we may deem unacceptable. The reason for the proposal was to help explore unknown threats. * Tobi: I don’t see the assets we’d be discussing defined. * Dimitris: In my mind, any rogue resolver between a CA and the authoritative name server could alter the results. The framing could be as simple as that. * Slaughter: In modeling terms, this is an abstract asset. For example, maintaining the integrity of the Web PKI. * Tobi: The asset is the correctness of issued certificates. * Corey re-framed the discussion. Defining the system components is a good start to begin evaluating this. I see this as a way of identifying potential problems with Method 7 that we might be able to improve by updating the BRs. It’s about identifying concrete improvements to bolster security. * Tobi: I think it contemplates extending the scope of DNS validation which should not be allowed. When we say in the BRs that we need to check DNS, it’s unfortunate that it could be misinterpreted as allowing a CA to simply check a resolver, rather than the authoritative resolver. I have a problem expanding the scope to include that - it would be a distraction. This practice should not be considered acceptable to begin with. * Slaughter: To make sure I understand, the mitigation is to only query authoritative name servers. This mitigates a threat that is available when you query recursive resolvers. * Tobi: Correct, you don’t know if a recursive resolver is telling the truth. It’s not trusted to be authoritative. This is fundamentally always true, unless when operated by the CA. * Slaughter: Summarizes - top-level threat - use of a 3rd-party recursive resolver can result in tampered or forged DNS responses being returned and relied upon during DCV. * [Corey began defining entities and components in the doc, and we discussed possible assumptions.] * Slaughter: Back to the threat, any recursive resolver can result in tampered/forged resolvers. I believe what Tobi is implying is that there are steps a CA can perform to mitigate that threat. * Tobi agreed that there are many mitigations possible. * [We iterated on the doc.] * Tobi: If you say you can use a third-party resolver, it means you can use any third-party resolver. And that is definitely a threat for the use case a CA is relying on for certificate issuance. * Corey: A similar issue is if you use a 1st party resolver and have no mitigations in place to prevent attacks. * Tobi: No. Because a third-party can lie to you. It’s not the same. * Corey: A first party resolver could be grossly misconfigured, we have no requirements for these systems. You can still have bad security outcomes. There’s a difference in who controls it. * Tobi: It’s still a threat, but it’s a different threat. * Slaughter: Both threats require different mitigations and should be addressed separately. * Corey: We're running out of time. There's an opportunity to clean-up the doc, I’ll share the URL on the Wiki and we can pick it up here at the next meeting. Meeting Adjourned -- You received this message because you are subscribed to the Google Groups "Management (CA/B Forum)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[email protected]> . To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/management/CADEW5O-HoNg%3DEvkG6RxMnTk8V_2RAaOv%3DAzh-K4ApWT_2aVVyA%40mail.gmail.com <https://groups.google.com/a/groups.cabforum.org/d/msgid/management/CADEW5O-HoNg%3DEvkG6RxMnTk8V_2RAaOv%3DAzh-K4ApWT_2aVVyA%40mail.gmail.com?utm_medium=email&utm_source=footer> .
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Validation mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/validation
