[cabf_validation] 2024-01-11 Validation-sc draft minutes

[Slaughter, Michael]

Validation Subcommittee – 11 January 2024
Minute Taker: Michael Slaughter (Amazon)

Attendees: Aaron Gable (Let's Encrypt), Aaron Poulsen (Amazon), Andrea Holland (VikingCloud), Aneta Wojtczak-Iwanicka (Microsoft), Ben Wilson (Mozilla), Bruce Morton (Entrust), Cade Cairns (Google), Clint Wilson (Apple), Corey Bonnell (DigiCert), Corey Rasmussen (OATI), David Kluge (Google), Dimitris Zacharopoulos (HARICA), Doug Beattie (GlobalSign), Dustin Hollenback (Microsoft), Eva Vansteenberge (GlobalSign), Gregory Tomko (GlobalSign), Inigo Barreira (Sectigo), Janet Hines (VikingCloud), Johnny Reading (GoDaddy), Mads Henriksveen (Buypass AS), Martijn Katerbarg (Sectigo), Michael Slaughter (Amazon), Michelle Coon (OATI), Nate Smith (GoDaddy), Paul van Brouwershaven (Entrust), Pedro Fuentes (OISTE Foundation), Rebecca Kelley (Apple), Rollin Yu (TrustAsia), Scott Rea (eMudhra), Sissel Hoel (Buypass AS), Stephen Davidson (DigiCert), Thomas Zermeno (SSL.com<http://ssl.com/>), Tobias Josefowitz (Opera Software AS), Trevoli Ponds-White (Amazon), Wayne Thayer (Fastly), Wendy Brown (US Federal PKI Management Authority)
Note: Paris = David Kluge (GTS)

Corey read the note well statement.
Agenda

  1.  Status update for the MPIC
  2.  Status update on Method 7 ballot
  3.  Delegated Third-Parties and Domain Validation
MPIC Update
Chris and Ryan will provide an update at the next meeting.

Aaron provided a link to the ballot and explained that the flurry of activity that has happened in the last 2 weeks is related to a single comment thread about the phrasing of a single sentence and that the majority of the ballot is stable.

Doug emphasized that time is of the essence since the dates start in the December and CAs will need time to perform planning and implementation.

Clint explained that delays were due to ongoing IPR agreement challenges with Princeton research team.

Aaron said that both the Google and the LE general consuls are working on this effort. The Princeton legal team has made a statement that it will never be appropriate for the Princeton team to sign the IPR agreement and join as an interested party

Trev said that we should talk about how we can handle future security researchers in a way that doesn’t require them to sign an IPR agreement when they are share findings rather than solutions.

Ben explained that the IPR agreement is mainly for protecting the CAs.

Dimitris clarified that the Princeton team did not just present findings, they also contributed to the solution. Dimitris said that the rules are not intended to protect CAs but rather the entire eco-system. If the forum requires MPIC but then someone implements royalties then that will have a negative impact on the eco-system.

Trev said that we are not going to raise the security bar unless we continue to receive feedback from researchers. We have to be able to engage with them without the expectation of an IPR. We should put together more forum level guidance so that we don’t run into this in the future.

Ben said historically, there was the Navy SSL patent which someone got a hold of that was used to extract money from multiple parities. Ben then agreed with Dimitris’ point about protecting the eco-system.
Method 7 Ballot Update
Slaughter provided background on the ballot and explained that he was able to capture the feedback from the previous discussion 30/11/2024 and it has been incorporated it into a new revision:  https://github.com/slghtr-says/servercert/pull/1/files.

Slaughter requested feedback on the updated language in the form of comments on the PR.
Delegated Third-Parties and Domain Validation
Corey introduced the 3rd topic of the meeting by explaining that the BRs are unclear about which aspects of the domain validation process are allowed to be performed by third-party services such as Google’s public DNS resolver. The purpose of this discussion is to try and build some consensus about what is appropriate and what is not.

Dimitris recalled the discussion to forbid delegated third parties from performing domain validation tasks and that it was his understanding is that the discussion was centered around the complete process of domain validation. He didn’t think the expectation of the forum was to deny any third-party component used as part on the process but rather who makes the final decision.

David Kluge said that the definition is relatively simple but not straightforward and explained that 3.2.2.4 clearly prohibits the use delegated third parties in main validation process and that delegated third party is defined as a different personal or legal entity that fulfills one or more of the CA’s requirements. David explained that this definition in the broadest interpretation could extend to Internet Service Providers (ISPs), Data Center Providers etc... at which point section 3.2.4 “collapses in on itself”. David then suggested that we look at a few examples and determine where it makes sense to draw the line between appropriate and inappropriate use of delegated third parties.

Trev said what confuses her about this is that there seems to be a consistent definition and that we expect the CA to exercise authority over the decision-making process. She added that when she thinks of delegating domain validation, she considers that as delegating the decision rather than the mechanism to get the information. The CA is responsible for exercising judgment over the data it receives.

Clint agreed that this is a pretty complex area of concern but thinks that the conclusion of the bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1872371) is correct. Clint said that CAs have to get data from the right sources which is why QIS and QGIS exist. For DNS data, third parties have to be involved based on how the internet works. In the process of validating a domain the CA may rely on third parties but the he would expect the protocol to be verified directly by the CA. For example, ensuring that DNS lookups are authoritative by directly connecting to the root zone and going down the DNS hierarchy. Clint said using 3rd party DNS resolver for example steps over that of being a “necessary” third party. Clint said we can come to an agreement on where that line exists and that it would be really good to add that clarity to the BRs.

Tobias: agreed with Clint and said there are two DNS protocols. 1) Between the client and stub resolver. 2) Between the resolver and the authoritative resolver and the only one’s worth checking are the authoritative ones. Tobias then asked if there was actual disagreement about whether or not using a third-party service for DNS resolution is acceptable if the language just needs to be improved.

David replied that at this point, the language is not as specific as it should be since it doesn’t distinguish between the different parts of the domain name system leaves it open for interpretation.

Tobias asked if there is agreement that using a 3rd-party DNS resolver should only be allowed if it is a dedicated 3rd party that is in the scope of audits.

David answered that he doesn’t know and that establishing what the concerns are might help.

Martijn said that we can look at the WHO-IS language as an example of where the language says the information has to be retrieved directly from the domain register or registry operator. The DNS language does not have that kind of specificity. Martijn agrees that we should only be using third-parties to request authoritative answers from browsers or registries directly and that we should make the text more around that.

Mads said that he will not argue about what is allowed and not allowed but as a CA that missed recently, I think there is some missing language in the BRs that is missing. Currently there is some practice that is accepted by the industry and some that are not but it is not obvious what is and what isn’t. Mads added that he hopes that we can add some language that helps clarify this for all of the domain validation methods.

Aaron said that he fundamentally agrees with Client that DNS lookups need to be made to an authoritative resolver. There were actually two issues with using Google DNS 1) They are a third-party which are forbidden and 2) Google Public DNS doesn’t commit to adhering to satisfying all of the requirements such as always performing DNS-SEC lookups. I think the second issue is why contacting the authoritative name server is the thing that is required and what needs to be clarified as the requirement. Aaron said that we need to be talking about this in the context of multiple domain validation methods including the File and CAA record-based methods that also rely on DNS lookups. DNS is required for 95% of the domain validation methods so we need to talk about this holistically. The second concern is how many CAs are using third-parties such as MailChimp to send e-mails for e-mail validation and does that count as a delegated 3rd party?

Dimitris said he tried to highlight some of those issues in the e-mail to the forum list on December 28th. Dimitris said Aaron mentioned an indirect requirement that comes from DNS SEC. and added that there are other requirements that come from other sources such as 5280 that have caused problems. Dimitris said we are talking about repeated incidents that is outside of domain validation which is a strong indication that something is wrong that we need to clarify or make more explicit. Dimitris added that there is no rule or requirement that an authoritative need to be queried as that indirectly comes from the DNS checks that CAs must perform.

Corey said there are two themes emerging: 1) Why is the use of a third-party problematic 2) the discussion on DNSSEC. Corey asked if anyone could provide an explanation on why there is a problem with delegating to third parties.

Dimitris clarified that we are talking about delegated third-parties as part of some component or function executed in the BRs but we don’t have any tools to create a lighter-weight audit for delegated 3rd parties. Dimitris added that it doesn’t really make sense from a security standpoint to required delegated third parties to be audited against the entirety of the BRs when they are only performing some function. He continued that this was part of the MPIC proposal for the remote vantage points.

David said he thinks it may helpful to frame the problem as a data quality concern. The delegated third-party discussion is about a legal-entity distinction but that is not what really matters for the quality of the validation. So, it may help to really focus on the reliability expectations of the third party.

Tobias said that it’s also about responsibility and that the CAs are responsible to the root programs and have oversight and the ability to react. He expressed the concern that if we just allow the usage of DTPs, we will not have the same degree of oversight.

Dimitris suggested to David that we bring in some risk analysis to the different components that could participate in the validation process. For example, a public DNS resolver and analyze if we can trust Google to not return wrong data and examine the probabilities.

Tobias responded that the problem is really difficult and that some of the big public resolvers are way more trust worthy. Specifying this out in a way that makes it acceptable is going to be really hard.

Trev said I think that Dimitris’ suggestion is right and we need to do a risk assessment or else we will continue to go round and round in fear circles.

Mads said that even if we found a DTP that is 100% reliable it’s still not allowed because it’s a DTP so he doesn’t believe that measuring the quality of the data is the way to go.

David said he things we could do an analysis to get a better understanding of the likelihood of these occurring because at this moment I think the discussion is purely conceptual since we don’t have any quantification for these scenarios.

Dimitris said a risk assessment that covers all DTPs including those for sending e-mails would be helpful.

Tobias said he thinks there is solid reason to draw the line where it is and that the idea that we could delegate the main validation out to DTPs is very problematic. Tobias said that DTPs are usually not operated to the level required, the requirements around validation would not be considered at every step along the way and their usage would make them vulnerable to attacks. He concluded that we would need a very complicated framework to determine when these are acceptable which he does not believe is worthwhile.

Mads said a risk assessment is something that we could use to help draw that line.

Aaron said for the sake of being able to continue the discussion, I sent a very simple clarification on how to clarify this language as a reply to Dimitris’ thread.

Dimitris asked for the thread to be forwarded to the server cert working group.

Corey said the language that Aaron sent out was treatment to a symptom and that we would also need a risk assessment exercise to identify the larger set of threats and potential resolutions.

Clint said addressing the symptom is worthwhile since it is currently an open wound and recommended that we also address 3.2.2.5. Tearing this apart for other purposes will have diminishing returns and would be challenging.

Aaron said he is fine with a two-prong approach but does not think the clarification should wait on the security assessment. I think the clarification should proceed at full steam ahead.

Corey asked if there is value in performing a risk assessment.

Dimitris said that once the experts start talking about a given topic like e-mail validation then it will lead to some useful productive discussion about the risks. threats and appropriate mitigations.

Corey concluded that we will spend some time on the next call and open the floor up to how we want to do the risk assessment.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20240123/afe0787a/attachment-0001.html>