[cabf_validation] 2023-08-10 Minutes of the Validation Subcommittee [DRAFT]

Thu Aug 24 01:05:29 UTC 2023

All,

Below DRAFT minutes from the August 10th meeting of the Validation WG.

August 10th meeting of the validation subcommittee.

Antitrust Statement: Corey Bonnell read the Antitrust Statement

Attendance

Aaron Gable - (Let's Encrypt), Aaron Poulsen - (Amazon), Aneta Wojtczak-Iwanicka-(Microsoft),  Ben Wilson - (Mozilla), Chris Clements - (Google), Corey Bonnell - (DigiCert), Dustin Hollenback - (Microsoft), Enrico Entschew - (D-TRUST), Gurleen Grewal - (Google), Li-Chun Chen - (Chunghwa Telecom), Martijn Katerbarg - (Sectigo), Michael Slaughter - (Amazon), Michelle Coon - (OATI), Nargis Mannan - (VikingCloud), Nate Smith - (GoDaddy), Paul van Brouwershaven - (Entrust),Pekka Lahtiharju - (Telia Company),  Rollin Yu - (TrustAsia Technologies, Inc.), Roman Fischer - (SwissSign), Ryan Dickson - (Google), Thomas Zermeno - (SSL.com), Tobias Josefowitz - (Opera Software AS), Wendy Brown - (FPKI), Wayne Thayer - (Fastly), Daryn Wright - (GoDaddy)

Approving minutes

- 2023-06-29: will be approved on August 24th, 2023.

- 2023-07-13: approved

Agenda:

  1.  Progress report from the multi-perspective domain validation team
  2.  Progress report from the domain validation threat modeling team
  3.  Discussion of Bruce’s email sent to the list: https://lists.cabforum.org/pipermail/validation/2023-July/001918.html

Corey: Are there any other agenda items you'd like to discuss today?

Wayne: I have a list of 3 things that have been thrown around on mailing lists that may or may not be relevant to the validation subcommittee. I thought it might be worth talking about each of those and whether we want to add those to our to our backlog or not.

Corey: We will put that as the 4th agenda item for today.

1. Progress report from the multi-perspective domain validation team

Ryan: Two updates on the multi-perspective efforts: the 1st related to the IPR. Unfortunately, no news related to the Princeton team's ability to sign the IPR. Again, I'd like to emphasize that this doesn't seem to be at all related to any indication that there is any concern about the Princeton team's ownership over IP or anything related to any of that. This just seems to be the wheels of involving lawyers and signing documents, but in the spirit of trying to move things along if there are questions from the community that we feel would be best addressed by the researchers sharing real world observations, data points that aren't yet considered or even just the opportunity to address or discuss concerns for members of the community related to the existing draft. We would be happy to schedule an ad hoc, multi-perspective, work team meeting, which we identified as an opportunity, or a place where the Princeton members of the team could participate in discussions in collaboration with other interested persons being anyone here in the forum. So, if there is interest in having one of these meetings to allow members of this community and larger community to directly interface with the researchers, the Princeton team said that they were happy to accommodate. I'll again offer that as a final point through these updates. In terms of the proposal itself, I will paste here in chat an updated pull request. We've been trying our best to address the comments and concerns that were communicated both on the original pull request and over a list to help make it clear as to what was being changed across versions of this effort, we created a separate branch. I'm not sure if everyone feels that that's the best approach, but we're really trying to make it obvious to readers and commenters what's changing from update to update of this effort just to help simplify the process. To generally describe the large changes that have been made since the original presentation of the subject matter. I think back in March, Doug had a valid concern that the name of the effort multi-perspective domain validation was too focused on, just that and it didn't appropriately consider multi-perspective CAA checking, which was defined as in scope of the effort. So, we've rebranded what was once known as multi-perspective domain validation to what is now called multi-perspective issuance corroboration. If there's any creative minds that think there's a better name for it, we're welcome to discuss, so feel free to provide that feedback. Another big topic of discussion related to the original proposal in terms of the quorum of corroborating network perspectives that must corroborate the perspectives of the primary CAA and domain validation perspectives, or the primary perspective. There was concern about somewhat loose definitions of continents, requirements at that time defined that at least 2 of the cooperating perspectives must be from distinct continents but depending on who you ask and where you look, you will find that there's anywhere between 5 and maybe 9 continents. So, to help improve that and just reduce ambiguity and improve clarity of the expectation we have since transitioned from requiring unique continents to saying that the perspectives must fall within the service regions of at least 2 distinct regional Internet registries. So, I hope it clarifies that and improves that language. The third item is that there was a lot of discussion on CAA checking and whether or not performing CAA checking from all these network perspectives and the number of perspectives required by quorum policies, whether that would introduce additional undue burden on CAs without providing clear security value. We discussed that perspective with the researchers from Princeton. Our conclusions were that we still feel like CAA checking is an important part of this process to be performed from multiple vantage points on the Internet, predominantly because we feel that it does offer an opportunity to prevent downgrade attacks.  We've cited some comments on those types of attacks in the common history on the GitHub, which is referenced in the pull request. But we also hear the concern from CAs, and we do consider it valid. The intent of this is to not make issuance of certificates harder or allow for an increase of false positives that would delay subscribers from obtaining certificates. We hoped to modify the language, which now basically identifies that we would expect multi-perspective domain validation or the evaluation of domains, their main validation process to happen from the number of perspectives required by the quorum at the time of issuance, or prior to issuance but lessening the strictness of the CAA check such that CAA checking could be reused. Basically, saying that if you perform multi-perspective issuance corroboration on the CAA record, you can reuse that record for the permitted timelines, identified in section 4.2.1. So, it gives you 398 days of reuse, which really equals 795 days of certificate validity, correlated to 1 check. Happy to collect the group's feedback on that.  I think the final item that we are still attempting to address is open for discussion, there was a comment as to whether or not it would be simpler for the requirements to represent like a standard, well defined percentage of corroboration. For example, saying that 80% of the perspectives must agree with the primary, versus the approach that we have right now, which is n-2 approach, which strengthens as the number of perspectives increases. We're trying to work with the researchers to get real world data to suggest that there is value in this strengthening approach or the significant value that warrants this somewhat level of complexity for the requirement. So, we're still working on addressing that concern but overall, we have been provided with research and it's included in the GitHub comments that the use of the MPVD regardless of a linear percentage or n-2 to approach by simply adopting this technology we're introducing significant value to the ecosystem and reducing likelihood of mis-issuance due to these attacks or hijacks. In terms of next steps, ideally, we would welcome and hope that members of the community can continue to share their comments and feedback on the pull requests. We're in no rush to push this forward. We do want to consider all perspectives from the community. As I mention in the beginning of this update, we would be happy to try to plan an ad hoc work team with the researchers such that members of this community could interface with them directly. We'd like to make sure that any lingering concerns or concerns from this community are absolutely addressed before we move forward. I think the only other point is that if you believe in the effort and would like to serve as an endorser for whenever future ballot is released, we would welcome that you can email us at Chrome Root Chrome or you can email Chris or I directly, and we'll work with you, as we look to finalize the draft, and then eventually move forward with the ballot in the Server Cert working group. Happy to answer any questions or comments on those updates.

Paul: One question regarding the CAA checking. Are you proposing that the CAA record doesn't have to be rechecked from multiple-perspectives or are you trying to loosen the entire CAA validation requirements?

Ryan Dickson: The multi-perspective CAA check would happen. So, let's assume that I'm issuing a certificate to ryandickson.me dot at that time the CA would perform domain validation from its primary data center. It would then kick off these subsequent checks or at the same time kickoff checks to perform MPDV and MPCAA, but if another certificate is issued to that domain in 30 days, for example, allow to reuse the original MPCAA check for up to 398 days. So, the idea is that we're still checking CAA from multiple perspectives, but we're introducing some flexibility on implementation such that that data can be reused for a longer period of time in hopes of necessitating added burden or increasing added burden on CAs for requiring that check for every issuance.

Paul: I don't think that necessarily answers the question. So, we don't do multi-perspective CAA check but the re-checking of CAA for that issuance after 30 days remains. Right?

Ryan: Before issuance CA has to check from its primary validation point as required by the BR, you still have to check CAA this doesn't change that requirement. This is just the additive check introduced by multi-perspective. Sorry, if I wasn't clear.

Paul: Thank you for clarifying that.

Aaron : I was just going to provide a different way of phrasing the same thing, but then Ryan clearly covered it.  I will be happy to endorse once we get to a final draft of the first version of the ballot. This is a thing to continue hashing out in the comments on the draft PR, but I have a feeling that the n -2 of version of number of perspectives feels more like good practices. Doing something like 80% feels like sort of explicitly opening the door to: "you can check from 100 perspectives and if 20 of them fail, that's just fine". I'm not sure we want to head in that direction both in terms of sort of implicitly allowing that much DNS queries spam and in terms of allowing that many failures. I think no matter how many perspectives you have if 20 of them fail, something feels very wrong. I don't know if that intuition is actually backed up by anything. I definitely look forward to hearing more from Henry and the rest of the Princeton team, but I think the sort of n + 2 failover size that many large Internet organizations have arrived at for redundancy of services and large distributed systems. I think that is sort of the best framework to inform how this should work. We're not looking for some percentage of these can be fooled and that's okay. We're looking for some percentage of these can fail and that's okay because of an Internet cut or delays in DNS propagation or something like that. I think when we're thinking about it, in terms of some number of them can fail what we really want to say is some number of them need to succeed and you're allowed to use 2 more than that to account for some amounts of failure. It's really n+2 in my mind. So, that's sort of off the top of the dome opinion on that.

Ryan: Thank you and that that's precisely the perspective we're trying to take, we would like to ensure if we were to use the simplified percentage-based approach that it would not meaningfully detract from the security value being added by the recommendation. We're hoping to make the determination based on data and evidence that's backed by scientific research and will be happy to share those updates whenever it's available. The Princeton team has been very accommodating and trying to answer these types of questions and also run experiments to corroborate claims that have been made in the past so really looking to do the best job possible to set us up on positive footing moving forward.

Corey: Thank you Ryan for the update. Are there any other questions or comments on a multi-perspective issuance corroboration?

Ryan: Yeah, I don't like it as much doesn't kind of roll off the tongue and pick versus MPDV, MPIC where we're at for now. It's the most complete name, I guess.

Corey: Cool yeah, I'll be sure to update that, and we send out the agenda moving forward. I guess if there's no other comments on that, we can move on to the second agenda item. I'm going to ask Slaughter, if he can provide an update on the domain validation threat modeling.

2. Progress report from the domain validation threat modeling team

Michael: A threat modeling team, which consists of Corey, Martin, Clinton myself, we've been making steady progress towards completing a threat model for a delegated DNS domain validation. We're collaborating asynchronously via a shared Google Doc, following a lot of the process that Brian outlined for MPIC, and we've had 2 working calls at this point to discuss the document in detail. To provide more insight, we're following the OWASP threat modeling process and template, which at a high-level causes for decomposing the system, determining and breaking threats to the system, identifying counter measures and mitigations. As a progress update, we're nearing the completion of a draft threat model. We've decomposed the system, clarified scope, identified a lot of assumptions and clarified trust levels. We've also created an initial list of threats using the stride model and proposed mitigations and will discuss them in a call later this week. The next steps are capturing the remaining discussion notes into the doc, publishing the draft, and reviewing that draft with this subcommittee and upcoming meeting so, we can gather additional feedback and perspectives. As a call out if you have any questions or interest in collaborating now, before we bring to this forum, please reach out to me at slaughter with no vowels at Amazon.com.

Corey: Thank you slaughter, are there any questions or comments on that progress?

Corey: Not hearing anything. Thanks again for presenting that really excited to see this work on being presented to a wider audience. Moving along to the 3rd agenda item: email from Bruce -> https://lists.cabforum.org/pipermail/validation/2023-July/001918.html

3. Discussion of Bruce’s email sent to the list: https://lists.cabforum.org/pipermail/validation/2023-July/001918.html

Corey: So, the TLS baseline requirements and I guess the code signing baseline requirements we'll also have this: "The CA SHALL enforce multi-factor authentication for all accounts capable of directly causing certificate issuance". Mozilla policy has roughly the same language but there is a carve out where there can be technical controls to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses.  I think Bruce's proposal is to basically take this carve out from Mozilla policy and add it to the TLS BRs.

Aaron: My question would be why/what's the motivation here? If the BRs already have the stricter form of this language, then presumably everyone is already compliant with the stricter form of this language. So, I would instead propose removing the carve out from the Mozilla language. Is there a specific use case here that someone wants to be able to take advantage of this carve out?

Paul: Bruce is not on the call today. I'm not sure exactly what the reasoning was for this email. I know there have been some thoughts or discussions around when an account directly capable of issuing a certificate. You can state that while if the same procedure involves domain control validation, then it's not direct issuance because there is a validation process in place like the subscriber account. For example, in an Acme environments. This is more a question from my side, I think then from Bruce,  if I have an Acme key, and I request a certificate, and then my Acme key is an account to the CA and that is capable of getting a certificate without human intervention. The restriction there is that there is domain control validation in between which I think is in line with the Mozilla statement. I don't know if that account is actually directly capable of issuing certificates or not. I think people can argue for both sites.

Aaron: Yeah, I think as an ACME CA operator, we do not take the position that subscriber accounts are "accounts capable of causing certificate issuance". Only our operator accounts are capable of causing certificate issuance and those accounts are. Subscriber accounts are only capable of requesting the certificate issuance. The accounts that are capable of causing certificate issuance are the accounts that have direct access to the machines that are connected to HSMs or are the HSMs themself, and those accounts obviously do have multi-factor, authentication and various other security measures.

Paul: I think that is a common interpretation, but it stays in interpretation, and I can feel and maybe even think that there could be best practice to say: should subscriber accounts also be restricted by multi-factor authentication to a certain degree? For ACME that could mean that there is a IP binding, and if the IP address changes that needs to be notified. Customer needs to approve that for example, it could be a second factor, but also, if someone's ACME key is compromised, then they could just continue requesting certificates through that key, potentially for pre-approved domains.

Ben: Does anyone not know the background or want to know sort of the background of this language? It was the Moto registration authority in Italy

that used a username and password or that somebody was able to figure out the password for the registration authority and issue some fraudulent certificates. So, that's what we're trying to address.

Paul: Yeah, that's where it originally came from. I don't think the language is ultimately clear because it doesn't talk about RA accounts for example, or it doesn't exclude subscriber accounts explicitly. So improving this language would be definitely something I vouch for but while we're at this point, I think it's also a good question: is that sufficient?

Martijn: If that's the intent of this language, is it not also redundant because don't we already enforce multi-factor authentication for what I would call CA accounts internal accounts through NSR?

Ben: Probably not, I wouldn't say it's redundant even if it were, it's not harmful. It's more beneficial to say it twice. If it is redundant, I'm not sure that it is.

Aaron: I think overall my off the top of the head stance is that I would be pretty opposed to adding carve out so that remove the requirement for multi-factor authentication. I think it's been pretty clearly shown the multi-factor authentication is the safest thing we have at the moment and creating carve outs that allow CAs to not have multi-factors set up for certain kinds of accounts just seems like a step backwards on all fronts. If we want to improve this language to make it clear that we are talking about some sort of CA operator accounts or RA operator accounts and not subscriber accounts, then that sounds just fine but I think that adding this carve out to the BRs is a step in the wrong direction.

Corey: I guess if I were to summarize the discussion, it sounds like maybe there would be recommended to add some clarity in Mozilla policy to better state what systems or accounts are specifically referring to, then potentially we can discuss longer term potentially looking at ways of increasing accounts security for subscribers. Is that a good summary of the discussion?

Ben: I don't know that we're going to be changing anything in the Mozilla policy unless somebody wants to put an issue in a GitHub to look at it further, but it wouldn't hurt to clarify the CA/Browser forum requirements to make them more similar to. I'm not seeing verbatim, but something that addresses the registration authority and delegated 3rd party functions.

Corey: I wish Bruce is on the call, so he can provide his perspective background.

Martijn: I just added the NSR language as well, just for reference in the chat for everyone's:  " Enforce Multi-Factor Authentication for all Trusted Role accounts on Certificate Systems (including those approving the issuance of a Certificate, which equally applies to Delegated Third Parties) that are accessible from outside a Secure Zone or High Security Zone; and"

Corey: Good, thank you. The language explicitly calls out that there are delegated 3rd party, so it's like that case would be covered in other ways. It sounds like we potentially have to move back to Bruce. I'm sure that maybe what we captured here today aligns with his perspective. So just to take that as an action item, I'll shoot Bruce an email and ask him to share his perspective. Is there any other discussion on multi-factor auth? Not hearing anything, I guess Wayne if you want to bring up the points that you wanted to raise earlier?

3. Three things from mailing list brought by Wayne (CAA validation for tor, the Peter Gutmann draft test keys, failed ballot to modify our week key checking language)

Wayne: Sure, I just noticed a few discussion threads that I thought may or may not be relevant to the validation subcommittee. I know that we're kind of in a transition state where we're working on getting the server certificate working group to a point where it can have more bandwidth to take on topics.

In the past, we've kind of maybe abused the scope of the validation subcommittee a little bit, so maybe some of these don't fit in validation subcommittee, but I thought I would just bring them up and see what folks thought about tackling them here versus elsewhere and what the priority was. The first one I think is most directly related to the validation subcommittee and to be honest I don't understand the topic all that well, but I know Aaron was engaged with Kim on this, and this was someone who has written a draft for an onion for a new domain validation for ACME. He was asking about CAA validation for tor services, and I think Tim suggested that we should talk about that in this very subcommittee. So, I thought that was the most obvious one that we might want to add to our backlog.

Corey: Yeah, I was actually going to reach out to them, the authors of the Internet draft of ACME for the tor domains. I wanted to see if they wanted to present at some point to this group. I know that there are interested parties that they have signed agreements, so there should be no issue with that. I will also confirm with Inigo that there'd be no issue with inviting them so, that is planned here sometime in the future.

Wayne: The current methods of domain validation would not support CAA or the current methods of tor domain validation would not require CAA. Is that right?

Corey: That's right. When this proposal becomes an RFC we may want to incorporate this in BRs, and maybe something above and beyond what's currently required.

Aaron: Yeah, I don't need to rehash the statements that I've made in emails both on the ACME mailing list and I think on one of the CA/B forum lists, although I forget which one. I'm very excited about the idea of CAA for all kinds of validation. I think it's the right direction to go, but I also think that the entire purpose of the tor specific validation methods is to allow validation without requiring CA to actually operate a tor clients and unfortunately the CAA checking method that has been devised still requires the CA to operate a tor client in order to check CAA, even though they don't need it to perform validation. So that, sort of defeats the purpose of the tor specific method, so I think there's something sort of going across purposes there and I'd like to see if there's any way to figure that out.

Wayne: Okay, so the other two are arguably not directly validation related. So, we may or may not want to tackle them here, but I'm also interested in hearing how people like the importance that how people feel,  one was a discussion around the Peter Gutmann draft test keys and whether that the fact that folks here are currently being made aware that there are compromised keys in a RFC out there somewhere on the Internet constitutes notice that the CA should  add those to their deny list for issuance. I think that's an area that I would like to see clarified in the BRs. I'm just interested if anybody else thinks that's important and/or something that we should tackle here versus the server certificate work group.

Wayne: Sounds like, nobody really is super worried about this.

Corey: I mean, it sounds like there's some really interesting discussion on the mailing list on the server cert working group. It sounds like there are some different perspectives, so probably does deserve to be clarified. My personal opinion, despite being a co-op on this Internet draft, is that there is no written obligation for the CAs to currently perform this checking with the keys that are described in the draft. I think personally it's a good practice, but I think given the different perspectives on the list, it would be good to have it clarified. Personally, I am leaning towards having this work being done in server cert working group, because this is really only very tangibly feels some validation related.

Wayne: Okay, I'm going to see if thumbs up from Aaron, so I will take that one to Inigo and I'm guessing we're going to decide the same on the other one, but I'll throw it out there anyways. That is the failed ballot, and I see Tom on the call as well, the failed ballot to modify our week key checking language is something that I don't think we reached consensus on, but I don't think that it was necessarily the ballot failed, because there was a sense that it wasn't a useful thing to do, but that it needed a little more discussion. So, my sense is that Tom is not planning to move forward with that, but I could be wrong about that. So, is their interest? What's the priority on that? Should it be in the validation subcommittee, or should we take it to the server cert working group?

Thomas: You are correct that I was not actively working on that at the moment. It might be better served in the server working group.

Wayne: So, just to make sure I'm clear, we should find someone who wants to own that and drive it forward like you don't want to take that forward at this point. Tom, is that right?

Thomas: Yeah, it's kind of been an albatross for us for quite some time. I don't know that we have the time or the wherewithal to follow it through.

Wayne: Totally understandable. Okay. Those were the three things, so it sounds like we're going to talk about CAA for tor here and the other two I will raise with Inigo. Thank you.

Corey: Yeah, thanks for raising that, if I recall correctly, I don't think we have the CAA for tor on our project list. I will take an action item to create it and have it in GitHub.

Wayne: Thanks.

Corey: All right, so we've reached the bottom of the agenda, are there any other topics that we want to raise for today?

Aaron: Just stating that I also intend to bring up the thread that has been happening on Mozilla dev security policy about cross certified, subordinate CA certificates. I intend to bring up at next week at the server cert meeting as well.

Corey: Yes, that'd be good to discuss.  Any other agenda items we want to raise for today? I guess not hearing anything I plan on having the next schedule meeting here in two weeks on the 24th, so looking forward to seeing everybody then. Thank you.

Meeting adjourned.

Thanks,

Aneta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20230824/6f747367/attachment-0001.html>