From doug.beattie at globalsign.com Mon Jul 15 12:47:44 2024 From: doug.beattie at globalsign.com (Doug Beattie) Date: Mon, 15 Jul 2024 12:47:44 +0000 Subject: [cabf_validation] Using dedicated DNS resolvers for domain validation In-Reply-To: References: Message-ID: During the last VWG call we had a good technical discussion on security concerns related to DNS resolvers being used for multiple purposes. There was agreement that CAs need to use a dedicated DNS resolver for domain validation even if we didn?t reach agreement on being permitted to use a third party resolver. I?m curious what the scope of ?domain validation? means in this regard. Can CAs use the same resolver for CAA, posting certificates to CT logs, doing who-is or RDAP queries, and if not, then maybe we should list more specifically what we mean by ?Dedicated resolver for Domain Validation? when it comes to this locked down resolver topic? Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 32161 bytes Desc: not available URL: From Corey.Bonnell at digicert.com Mon Jul 15 14:08:16 2024 From: Corey.Bonnell at digicert.com (Corey Bonnell) Date: Mon, 15 Jul 2024 14:08:16 +0000 Subject: [cabf_validation] 2024-05-02 Final Meeting Minutes Message-ID: ## Validation Subcommittee Minutes | Thursday, 2024-05-02 ### Attendance Aaron Gable (Let's Encrypt), Aaron Poulsen (Amazon), Abhishek Bhat (eMudhra), Adriano Santoni (Actalis S.p.A.), Andrea Holland (VikingCloud), Ben Wilson (Mozilla), Bruce Morton (Entrust), Clint Wilson (Apple), Corey Bonnell (DigiCert), Corey Rasmussen (OATI), Doug Beattie (GlobalSign), Enrico Entschew (D-TRUST), Gregory Tomko (GlobalSign), Gurleen Grewal (Google), I?igo Barreira (Sectigo), Janet Hines (VikingCloud), Jay WIlson (Sectigo), Johnny Reading (GoDaddy), Keshava Nagaraju (eMudhra), Luis Cervantes (GoDaddy), Mads Henriksveen (Buypass AS), Mahua Chaudhuri (Microsoft), Martijn Katerbarg (Sectigo), Michael Slaughter (Amazon), Michelle Coon (OATI), Miguel Sanchez (Google), Nargis Mannan (VikingCloud), Nate Smith (GoDaddy), Naveen Kumar (eMudhra), Paul van Brouwershaven (Entrust), Pedro Fuentes (OISTE Foundation), Rebecca Kelly ( SSL.com), Rollin Yu (TrustAsia), Roman Fischer (SwissSign), Scott Rea (eMudhra), Stephen Davidson (DigiCert), Thomas Zermeno ( SSL.com), Tim Hollebeek (DigiCert), Tobias Josefowitz (Opera Software AS), Trevoli Ponds-White (Amazon), Wayne Thayer (Fastly), Wendy Brown (US Federal PKI Management Authority) ### Note Well The statement was read concerning the meeting recording, antitrust policy, code of conduct, and intellectual property rights agreement. ### Approval of minutes The minutes for the March 21st 2024 meeting of the Validation Subcommittee were approved. The minutes for the April 4th 2024 meeting of the Validation Subcommittee were approved. ### Discussion - Identifying DTPs in the context of domain validation #### Method 2 > Reviewed method 2?s use of email, fax, SMS, and postal mail Aaron G: We?ve discussed previously the use of MailChimp-style email providers, this one adds the possibility of something like Twilio being used. Tim H: It?s possible 3rd party Operating Systems are in use as well. Aaron G: Maybe we care about the targeting of the random value, but not the transport mechanism. That may inform what?s considered a delegated third party (DTP). What you use to look up the Domain Contact has to be very carefully controlled and not use DTPs. The transmission from the Domain Contact doesn?t matter as long as the correct Domain Contact received the random value. Tim H: We need a threat model and security analysis of which components materially affect the integrity of the validation process. Some hypotheticals are many levels removed from the actual security, critical properties of the system. Aaron G: Right, if the CA has correctly determined the Domain Contact without using any 3rd party then an Email or SMS hijack is equivalent to a BGP hijack in Methods 18 and 19. Tim H: The improvements we?re trying to make aren?t even related to what is or isn?t a DTP; that?s a bit of a red herring. It?s really about a security analysis of what components are security critical and weren?t included in previous analyses of the security properties of these methods. ?? should focus on what are the actual critical security properties of each of the parts of these validation methods and are there any things that are outside the control of the CA that could potentially compromise the integrity of the validation process. Aaron G: Applying that to Method 2, we don?t care about the transmission of the random value from the Domain Contact to the CA, but getting the random value to the correct Domain Contact so you can prove they?ve received it is very hard. Tim H: This method also mixes together 3 completely unrelated things that have different security properties, which makes this method difficult to analyze. Is postal mail still used? Corey B: There are probably a couple smaller European teams that do Tim H: This method is interesting in that it?s verifying control over an email, fax, or SMS number that was found as contact information from a trustworthy source. Roman F: An interesting property of using postal mail is you can do Registered Mail and have legal proof that it has been received. If you use a fax or SMS, you?re probably going to use a 3rd party provider. Maybe this should be taken apart. Aaron G: It?s interesting that any node along the transmission path to the Domain Contact can pretend to be the Domain Contact and reflect it back. Tim H: It?s usually better to get the value back via some sort of authenticated portal, and I think that?s how it?s done for most these days. Aaron G: If that were required, it would bring this closer to other methods. Tobias J: Why is that? I can sign up for an account with the CA and enter the random value in, but if I?m getting that random value from a stolen email then the authenticated portal doesn?t change anything. Aaron G: Agreed, but if we?re accepting that control of an email, fax, SMS, or mail address is equivalent to control of a domain, then it brings it to the equivalent level of Methods 18 and 19 where an attacker could apply for the certificate and do a BGP hijack as opposed to a postal mail hijack. Tobias J: If you can just reply to the email or take something from the email and enter it into a website, I don?t see where the difference is. It seems to make a difference for some and I?m not understanding why. Aaron G: That?s a fair point. It makes it more symmetric with other methods, but I think you?re right that it doesn?t meaningfully improve the security. Trev P: Are we listing DTPs that can be used with this method? I assume it?s okay to use commercial and government postal services? Tobias J: Is that a DTP? The government approved postal or phone service is the authoritative way of delivering to a postal address or phone. I?m synthesizing that understanding from this method?s use of postal mail. A postal mail address works in that sense that it defines the recipient that can be reached via the postal mail service ? it?s an intrinsic part of this transaction. Tim H: So you?d you also agree that commercial email providers are the standard way of sending emails and therefore using a 3rd party commercial email provider is completely appropriate for sending emails. Tobias J: No, because the email address as the recipient is defined in the DNS. You hand over your message to that record, not to a commercial service that then does the lookup itself. Tim H: There?s no requirement that you hand your mail over to the post office, you could have some 16 year old intern running the mail over to the post office. Email addresses are just an identifier to identify someone on the internet, the same way an address or phone number is. Tobias J: If you have 16 year old interns handling the mail, you?re responsible for that. You?ve screened them, you?re aware of the contexts surrounding what they?re doing, how it?s structured, etc. Tim H: As a CA, I?m responsible for email communication as well. I?m not going to delegate that to some untrusted person. In the same way we take very seriously who handles outbound postal mail. The idea that there?s a distinction between using a standard commercial service for email is not okay but somehow for postal mail, because the post office is a government entity, it?s totally okay. Tobias J: It?s not because the post office is a government entity, it?s because the service is intrinsic to how postal mail is and can be delivered to you. Trev P: Going back to when you have someone taking your mail to the mailbox, and you have some kind of oversight. To me that?s the same thing you do with a company that you use for a service. The best you can do is get the assurances that you can, and with a company you get more assurances by reviewing 3rd party audits. It just seems a little mystical to make the distinction between FedEx, UPS, the Post Office; and Twilio. Clint W: I?m hearing that this method may include use of services that are sort of intrinsically DTPs, for some aspects of the method, and it?s maybe not a suitable validation method. Tim H: You can say the same thing about DNS services and therefore they?re all not suitable validation methods. Clint W: I?m not sure; I don?t think I would agree with that because a CA *can* access authoritative DNS records directly, they *can* send email directly to an MX record of a mailbox; they can?t send postal mail directly to a postal mail address - unless they really want to. Trev P: The point that you?re raising is why I think we?ve run ahead of ourselves and redefined the intent of what a DTP was supposed to mean. If you look at the historical discussion, the intent was when you delegated away all of the decision-making, not random pieces of technology that your CA has probably assessed along the way that you use to help. So the entire discussion we?ve had about this method and so much of it intrinsically relies on 3rd party services is a good example of how I don?t think the intent of forbidding DTPs was to be ?you can?t use any piece of technology?. Tim H: That?s why I brought up the Operating System examples. Historically, this was when RAs were doing all of the validation (but not actually doing any validation) and then those validation results were relied upon by major CAs at the time. That behavior is what this was intended to prevent. The rat hole that it?s gone down where you?re worried about whether the electricity providers or Operating Systems are DTPs needs a nice clear definition of what exactly a DTP is and what the criteria are, including "is there actually a good security model for the validation method?? and ?is this DTP actually critically involved in the security of the method?? Clint W: Are we back to the framework that Aaron G. proposed near the beginning of the call, saying we?re mostly worried about the generation of random values and the delivery of the random value to the correct contact, and after that it doesn?t matter as much? The receipt of that random value, wherever it comes from, is delivered to the Domain Contact. If the Domain Contact sends it to somebody else or shares it or whatever, that?s their prerogative. If the CA receives it in association with the Request it was generated for, it?s valid. Is that model the right thing to be talking about instead? Tim H: Absolutely. Another thing is that there are really 2 types of random values. There are bearer tokens and secrets. In method 2 it?s a secret random value, so all we?re worried about is whether it can be transmitted securely to the intended recipient, which is the person identified by the identifier (email address, phone number, or physical address) that was specified. That?s the scope of the security requirements method 2. Martijn K: I would add that method 7 is the opposite way. We wouldn?t care who we send it to so long as the person that wants the certificate can create the DNS record. Aaron G: I think I end up with there being a lot of things that could be considered a DTP involved in the transmission of the random value, e.g. Twilio, MailChimp, USPS, etc. and I think we?re choosing to mostly not care about those. The important thing is to care about how the CA looks up the Domain Contact. Tim H: CAs are on the hook for this, so if you choose a bad provider you?re not immune to repercussions for your customers. If the provider doesn?t keep the emails secret, for example, you might end up needing to revoke all your certs. Corey B: The essential element is the CA take responsibility for the validation process. If there is some 3rd party component that?s compromised in any way the CA has to rectify that. The other methods we?ve discussed (18-20 and 7) all use a ?freshness? random value and method 2 uses a ?secret? random value, so the transport of this random value is much more critical than the other ones. Should we eventually enumerate the 3rd party components that can be used for this and then do a security analysis on these, and then do a ballot? Tobias J: What are the reasons we can?t discontinue this? Is it in use? Tim H: Absolutely, it?s pretty common. Clint W: Are fax, SMS, and postal mail in use? Tobias J: I could disagree more with what?s been said, but I don?t want to go through that because I?m very concerned with many aspects of this method, especially if we say it?s fine to use DTPs all the way or anything like that? I don?t want to have that discussion unless it?s necessary, so I would like to know what aspects of this method are actually relevant? Clint W: My thought was, if nobody?s using certain aspects of method 2, then we can avoid doing a security analysis and spending time them. If there?s some consensus that we can eliminate aspects of method 2, that would help us avoid spending time on parts of this. Trev P: I agree we can discuss this method in the future, but that?s not really Corey?s question. Corey: I think it?s best to separate the discussions of this method in relation to DTPs vs the merits of retaining different mechanisms in this method. Martijn K: The more I think about it, the more I realize how very insecure the postal method is. I think we should scrap it as soon as we can, but maybe people have other opinions. Mads H: I agree that the way to find the proper Domain Contact is an important part of this validation method. We also have several methods that use email as the transport mechanism, so that is worth looking into. I also agree that, as presented now, security is not very good independent of whether a CA using using a DTP or not. I think we heard earlier the discussion about if the Domain Contact presents the random value or request token in a portal, it should be an authenticated portal where it?s possible to see that it?s an actual representative of the Applicant; that could be one direction to move this. Corey B: In the spirit of moving things forward, do we want to table this discussion and in the near future we?ll go through each communication mechanism and identify potential 3rd party components that can be used, perform a security analysis on those, and look at language improvements for this method Does that sounds like a good path forward? Mahua C: Is there a way to separate fax, SMS, postal mail from email with this method and discussion? Corey B: I think that would be valuable to pare down the available communication mechanisms, but I?m worried that it would push back the overall discussion we?re trying to accomplish. Clint W: I agree, but I think from this discussion I see that forking this might make sense. Maybe tabling the analysis of this method for the time being and continuing with other methods. There are a couple things that have come out of this discussion that seem worth continuing to follow up on. 1) The random value. I think we have a GitHub issue for this, but splitting it into the ?secret? vs ?not-secret? random values to make it clearer and when we get to the security analysis, we?ll need that concept defined anyway. 2) Looking at this method and whether we can deprecate it or replace it with a method that?s only email or replace it with separate methods for email, SMS, fax, and postal mail ? something that would allow for future changes that remove some of the components of this method that are unused and aren?t necessary to remain in the BRs. That?s how I?m seeing it; I know that doesn?t directly address the next steps for the DTP assessment, but I?m not sure that?s as valuable for this method given what?s been discussed and identified today. Trev P: It?s still not clear to me what part of the internet for sending email constitutes a DTP. I think the ballot we did before was overzealous and not in line with the intent of DTPs. Clint W: We?re going to continue with other methods that use email, so we?re still going to be talking about email and DTPs, which I totally agree is something we need to spend more time on, I just don?t think we need to spend more time on fax and postal mail. Aaron G: I generally agree, but it?s not clear to me that tabling discussion will be super helpful given that all of the methods we have left are either email or phone contacts and different ways to obtain those contacts. So email and phone are going to be topics for the rest of the DTP discussions. Clint W: Yeah I?m specifically just saying fax and postal mail should be tabled. Trev P: I feel like tabling them is just avoiding the issue that we?ve retconned a definition of DTP that didn?t exist. We were just like ?oh well now we think it means this?, but as we dig into it we?re realizing it can?t mean what we decided it meant a few months ago when it was put in, because when you examine these DTPs in the validation methods, they fall apart. Tim H: I don?t know what delegated third party means in the context of the Baseline Requirements. I can say there?s a bunch of stuff discussed on MDSP or its successor list and there are incidents, but the only thing I can really conclude is nobody in the industry, even the experts, has a precise definition or understanding of what DTP is. And for something that?s part of our critical compliance requirements, that situation can't persist. We can argue about which methods are not good, but until we come up with objective criteria about what a DTP is we?re just going to go in circles for years. Corey B: So maybe next meeting we spend the first 20 minutes circling back on the definition of DTP and then work on the F2F agenda. Meeting adjourned. ### Action Items & Next Steps 1. Consider breaking apart Method 2 and/or deprecating some of its supported mechanisms for performing domain validation 2. Revisit the idea of separating the current concept of ?random value? into 2 which incorporate the expectation that the random value be kept secret (or not) 3. Continue reviewing validation methods in the context of third parties and DTPs -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5231 bytes Desc: not available URL: From Corey.Bonnell at digicert.com Mon Jul 15 14:56:38 2024 From: Corey.Bonnell at digicert.com (Corey Bonnell) Date: Mon, 15 Jul 2024 14:56:38 +0000 Subject: [cabf_validation] 2024-05-30 Final validation-sc Meeting Meetings Message-ID: These are the Final Minutes of the Teleconference described in the subject of this message, prepared by Martijn Katerbarg(Sectigo). ==Note Well== Corey read the Note Well. ==Attendees== Aaron Poulsen (Amazon), Abhishek Bhat (eMudhra), Adrian Mueller (SwissSign), Adriano Santoni (Actalis S.p.A.), Andrea Holland (VikingCloud), Andreas Henschel (D-TRUST), Antti Backman (Telia Company), An Yin (iTrusChina), Arno Fiedler (ETSI), Arvid Vermote (GlobalSign), Ben Wilson (Mozilla), Bruce Morton (Entrust), Chorus Li (iTrusChina), Christophe Bonjean (GlobalSign), Chya-Hung Tsai (TWCA), Clint Wilson (Apple), Corey Bonnell (DigiCert), Dave Chin (CPA Canada/WebTrust), Dean Coclin (DigiCert), Devon O'Brien (Google), Dimitris Zacharopoulos (HARICA), Dong Wha Shin (MOIS (Ministry of Interior and Safety) of the republic of Korea), Doug Beattie (GlobalSign), Eva Van Steenberge (GlobalSign), Hannah Sokol (Microsoft), Hogeun Yoo (NAVER Cloud Trust Services), Inaba Atsushi (GlobalSign), Inigo Barreira (Sectigo), Janet Hines (VikingCloud), Jeremy Rowley (DigiCert), Joanna Brawata (Asseco Data Systems SA (Certum)), John Sarapata (Google Trust Services), Josselin Allemandou (Certigna), Jozef Nigut (Disig), Kateryna Aleksieieva (Asseco Data Systems SA (Certum)), Keshava Nagaraju (eMudhra), Kiran Tummala (Microsoft), Leo Grove (SSL.com), Luis Cervantes (GoDaddy), Mads Henriksveen (Buypass AS), Mahua Chaudhuri (Microsoft), Marco Schambach (IdenTrust), Martijn Katerbarg (Sectigo), Mats Rosberg (Keyfactor), Matthias Wiedenhorst (ACAB Council), Michal Malinowski (Asseco Data Systems SA (Certum)), Miguel Sanchez (Google Trust Services), Michelle Coon (OATI), Mohit Kumar (GlobalSign), Mrugesh Chandarana (IdenTrust), Nargis Mannan (VikingCloud), Nate Smith (GoDaddy), Naveen Kumar (eMudhra), Nick France (Sectigo), Nicol So (CommScope), Paul Brown (GlobalSign), Paul van Brouwershaven (Entrust), Pedro Fuentes (OISTE Foundation), Pekka Lahtiharju (Telia Company), Peter Miskovic (Disig), Prachi Jain (Fastly), Puja Sehgal (Microsoft), Rebecca Kelly (SSL.com), Rob Stradling (Sectigo), Romain Delval (Certigna), Roman Fischer (SwissSign), Ryan Dickson (Google), Scott Rea (eMudhra), Sissel Hoel (Buypass AS), Stefan Kirch (Telekom Security), Stephen Davidson (DigiCert), Sven Rajala (Keyfactor), Tadahiko Ito (SECOM Trust Systems), Thomas Zermeno (SSL.com), Tim Callan (Sectigo), Tim Crawford (CPA Canada/WebTrust), Tim Hollebeek (DigiCert), Tobias Josefowitz (Opera Software AS), Trevoli Ponds-White (Amazon), Tsung-Min Kuo (Chunghwa Telecom), Wayne Thayer (Fastly), Wei-Hao Tung (Chunghwa Telecom), Yoshihiko Matsuo (Japan Registry Services) ==Agenda== No changes to the agenda are requested. ===Report on progress since F2F #61=== No discussion based on the presentation provided by Corey. Presentation is attached to this email. ===Discussion on converting validation-sc to the validation-wg=== Corey presented a background and proposal for transforming the validation subcommittee into a working group. Presentation is attached to this email. Martijn asks what the idea is around creating a new document, and allowing working groups to incorporate that, but also override it. Corey confirms that yes, that indeed should be possible, although we should be careful with overriding items. Much like the NSRs are now incorporated based on a specific version, this potential document could be used in the same way. Tim H. raises the option of making this document a library type of document, so each working group can decide for themselves which methods they would like to allow. Wayne states he's not very keen on having such a setup, where each working group would need to update the version every time there is a change. Tim H. brings up the option about doing a single cross-working group ballot, although this needs to be allowed in the Bylaws. Paul points this out as a probable problem. Alternatively the Validation WG could potentially be setup as a cross-working group-group, again with Bylaws changes. Clint points out this is likely non-starter for Apple's participation. Wayne adds that for IPR protection we need to be keeping to a single working group. It seems we don't directly have an end-goal in mind, while we seem to be continuing to create more working groups. Paul provides the option of having SCWG members automatically become members of the ValidationWG, something much relate to how they currently become members of the ValidationSC. Would that not clear IPR issues if the ballot passes in the ValidationWG? Tim H. adds that there's currently no such thing as a cross-working group, not even the Forum is that. We need to figure out how this would work. Clint raises concerns with the cost-vs-benefit of doing this transformation. There were differing perspectives on the idea, with some expressing skepticism and concerns about potential conflicts of interest. The next step proposed was to create a charter for the working group to further inform the discussion and address concerns. ===Improvement on language for the serialNumber attribute for Government Entities=== This discussion was moved to the next meeting instead. === 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 management+unsubscribe at groups.cabforum.org. To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/management/SA1PR17MB 65031B96AA60F3F41C7E2503E3C82%40SA1PR17MB6503.namprd17.prod.outlook.com. From: 'Martijn Katerbarg' via Management (CA/B Forum) > Date: Tuesday, 25 June 2024 at 13:28 To: management at groups.cabforum.org > Subject: [management] Draft Minutes of the Validation Subcommittee F2F-62 May 30, 2024 These are the Draft Minutes of the Teleconference described in the subject of this message, prepared by Martijn Katerbarg (Sectigo). Please review the minutes and propose edits if necessary. These minutes will be considered for approval at the next meeting. ==Note Well== Corey read the Note Well. ==Attendees== Aaron Poulsen (Amazon), Abhishek Bhat (eMudhra), Adrian Mueller (SwissSign), Adriano Santoni (Actalis S.p.A.), Andrea Holland (VikingCloud), Andreas Henschel (D-TRUST), Antti Backman (Telia Company), An Yin (iTrusChina), Arno Fiedler (ETSI), Arvid Vermote (GlobalSign), Ben Wilson (Mozilla), Bruce Morton (Entrust), Chorus Li (iTrusChina), Christophe Bonjean (GlobalSign), Chya-Hung Tsai (TWCA), Clint Wilson (Apple), Corey Bonnell (DigiCert), Dave Chin (CPA Canada/WebTrust), Dean Coclin (DigiCert), Devon O'Brien (Google), Dimitris Zacharopoulos (HARICA), Dong Wha Shin (MOIS (Ministry of Interior and Safety) of the republic of Korea), Doug Beattie (GlobalSign), Eva Van Steenberge (GlobalSign), Hannah Sokol (Microsoft), Hogeun Yoo (NAVER Cloud Trust Services), Inaba Atsushi (GlobalSign), Inigo Barreira (Sectigo), Janet Hines (VikingCloud), Jeremy Rowley (DigiCert), Joanna Brawata (Asseco Data Systems SA (Certum)), John Sarapata (Google Trust Services), Josselin Allemandou (Certigna), Jozef Nigut (Disig), Kateryna Aleksieieva (Asseco Data Systems SA (Certum)), Keshava Nagaraju (eMudhra), Kiran Tummala (Microsoft), Leo Grove (SSL.com), Luis Cervantes (GoDaddy), Mads Henriksveen (Buypass AS), Mahua Chaudhuri (Microsoft), Marco Schambach (IdenTrust), Martijn Katerbarg (Sectigo), Mats Rosberg (Keyfactor), Matthias Wiedenhorst (ACAB Council), Michal Malinowski (Asseco Data Systems SA (Certum)), Miguel Sanchez (Google Trust Services), Michelle Coon (OATI), Mohit Kumar (GlobalSign), Mrugesh Chandarana (IdenTrust), Nargis Mannan (VikingCloud), Nate Smith (GoDaddy), Naveen Kumar (eMudhra), Nick France (Sectigo), Nicol So (CommScope), Paul Brown (GlobalSign), Paul van Brouwershaven (Entrust), Pedro Fuentes (OISTE Foundation), Pekka Lahtiharju (Telia Company), Peter Miskovic (Disig), Prachi Jain (Fastly), Puja Sehgal (Microsoft), Rebecca Kelly (SSL.com), Rob Stradling (Sectigo), Romain Delval (Certigna), Roman Fischer (SwissSign), Ryan Dickson (Google), Sissel Hoel (Buypass AS), Stefan Kirch (Telekom Security), Stephen Davidson (DigiCert), Sven Rajala (Keyfactor), Tadahiko Ito (SECOM Trust Systems), Thomas Zermeno (SSL.com), Tim Callan (Sectigo), Tim Crawford (CPA Canada/WebTrust), Tim Hollebeek (DigiCert), Tobias Josefowitz (Opera Software AS), Trevoli Ponds-White (Amazon), Tsung-Min Kuo (Chunghwa Telecom), Wayne Thayer (Fastly), Wei-Hao Tung (Chunghwa Telecom), Yoshihiko Matsuo (Japan Registry Services) ==Agenda== No changes to the agenda are requested. ===Report on progress since F2F #61=== No discussion based on the presentation provided by Corey. Presentation is attached to this email. ===Discussion on converting validation-sc to the validation-wg=== Corey presented a background and proposal for transforming the validation subcommittee into a working group. Presentation is attached to this email. Martijn asks what the idea is around creating a new document, and allowing working groups to incorporate that, but also override it. Corey confirms that yes, that indeed should be possible, although we should be careful with overriding items. Much like the NSRs are now incorporated based on a specific version, this potential document could be used in the same way. Tim H. raises the option of making this document a library type of document, so each working group can decide for themselves which methods they would like to allow. Wayne states he's not very keen on having such a setup, where each working group would need to update the version every time there is a change. Tim H. brings up the option about doing a single cross-working group ballot, although this needs to be allowed in the Bylaws. Paul points this out as a probable problem. Alternatively the Validation WG could potentially be setup as a cross-working group-group, again with Bylaws changes. Clint points out this is likely non-starter for Apple's participation. Wayne adds that for IPR protection we need to be keeping to a single working group. It seems we don't directly have an end-goal in mind, while we seem to be continuing to create more working groups. Paul provides the option of having SCWG members automatically become members of the ValidationWG, something much relate to how they currently become members of the ValidationSC. Would that not clear IPR issues if the ballot passes in the ValidationWG? Tim H. adds that there's currently no such thing as a cross-working group, not even the Forum is that. We need to figure out how this would work. Clint raises concerns with the cost-vs-benefit of doing this transformation. There were differing perspectives on the idea, with some expressing skepticism and concerns about potential conflicts of interest. The next step proposed was to create a charter for the working group to further inform the discussion and address concerns. ===Improvement on language for the serialNumber attribute for Government Entities=== This discussion was moved to the next meeting instead. === Meeting adjourned === -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2024 Summer Validation SC.pdf Type: application/pdf Size: 156382 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5231 bytes Desc: not available URL: From Corey.Bonnell at digicert.com Mon Jul 15 14:57:57 2024 From: Corey.Bonnell at digicert.com (Corey Bonnell) Date: Mon, 15 Jul 2024 14:57:57 +0000 Subject: [cabf_validation] 2024-06-13 Final validation-sc Meeting Minutes Message-ID: These are the Final Minutes of the Teleconference described in the subject of this message, prepared by Dimitris Zacharopoulos (HARICA). Note-well Corey read the note-well. Attendees Aaron Gable - (Let's Encrypt), Aaron Poulsen - (Amazon), Ben Wilson - (Mozilla), Corey Bonnell - (DigiCert), Corey Rasmussen - (OATI), Dimitris Zacharopoulos - (HARICA), Doug Beattie - (GlobalSign), Enrico Entschew - (D-TRUST), Eva Vansteenberge - (GlobalSign), Gregory Tomko - (GlobalSign), Johnny Reading - (GoDaddy), Joseph Ramm - (OATI), Mahua Chaudhuri - (Microsoft), Martijn Katerbarg - (Sectigo), Michael Slaughter - (Amazon), Michelle Coon - (OATI), Nate Smith - (GoDaddy), Paul van Brouwershaven - (Entrust), Pedro Fuentes - (OISTE Foundation), Rebecca Kelly - (SSL.com), Scott Rea - (eMudhra), Stephen Davidson - (DigiCert), Thomas Zermeno - (SSL.com), Tobias Josefowitz - (Opera Software AS), Wayne Thayer - (Fastly), Wendy Brown - (US Federal PKI Management Authority). Agenda Pedro proposed to discuss the role of QGIS when used as a validation source. Enrico proposed to add an agenda topic for a proposal regarding section 7.1.2.7.7. Approval of minutes * 2024-05-16. Minutes were distributed. Members will have time to review and approve at the next meeting. 1. Improving requirements for EV registration numbers (this is the topic we didn't get to at the F2F) Corey referred to a public incident in Bugzilla that inspired this proposal and went through the summary of the issue. Registration Numbers apply only to Private Organizations and the language in the EV Guidelines needs to be more consistent. The proposal tries to clarify the expectations for Registration Numbers for Government Entities and other types. Corey went through the draft language in https://url.avanan.click/v2/___https://github.com/CBonnell/servercert/pull/6 /files___.YXAzOmRpZ2ljZXJ0OmE6bzphMjkxNGFhMTM5NWViNDkzODQ2ZjUwY2YwNTgwNzE2ZD o2OjZhZTE6YWYwNWMxNjZhYjFhYTg2NmM3ZmQ2N2QzOTZhOTgyYWFmMmZjYzA1YmQ2ODFmZTMxOD BlM2VjZGQ1ZDZkYjM4Yjp0OkY and provided explanations of the changes. Dimitris noted that the "Date of Formation" language in the Non-Commercial Entity Subjects should also include the previous language regarding the legal act of formation. Corey agreed and noted that he doesn't intend to start a ballot soon so there will be time for Members to evaluate and propose improvements or raise concerns. After discussing the concrete language improvements that are not effectively changing any existing requirements, perhaps there is an opportunity to add specific improvements, like mandating a specific date format, "appropriate language to indicate the Subject is a Government/Non-Commercial Entity"? 2. Delegated Third Parties and DCV: where did this requirement come from and how did we get here? (a discussion of the historical origins of this requirement as it was deemed useful to have on our previous call on the DTP topic) Decided to spend time at the next meeting. 3. The role of the QGIS when used as a validation source Aggregators or other governmental services and can be used as verification sources. Registration or Incorporating Agencies do not always provide public access, making it very difficult to use Pedro shared the proposed language in https://url.avanan.click/v2/___https://github.com/cabforum/servercert/pull/5 10/files___.YXAzOmRpZ2ljZXJ0OmE6bzphMjkxNGFhMTM5NWViNDkzODQ2ZjUwY2YwNTgwNzE2 ZDo2Ojk0Nzc6N2NlMTc4NDEzYzc2OWM0ZTNhMDAwOTc0ZTczNDEzYmViZDE1MGY3NGZiMTk3MThm OTJhNjBkYTliMmI1ZWE3Nzp0OkY and walked through the changes. The proposal is to add the QGIS as an appropriate verification source in addition to the Registration/Incorporation Agencies. Dimitris noted that we must be careful with the aggregators for governmental services and should not consider aggregators in general as QGIS. Corey recommended starting an email thread to solicit feedback. 4. Proposed change to BRs section 7.1.2.7.7 Enrico described an issue with adding LDAP URLs in the CRLDP, and wants to propose language to adjust the BRs to make this requirement clearer. He shared a github redline with language taken primarily from the S/MIME BRs. The group agreed that the language in the S/MIME BRs seems clearer and easier to read/implement. Dimitris noted the use of the term "HTTP scheme" and asked if this is a used term vs a "HTTPS scheme". Corey pointed to https://url.avanan.click/v2/___https://datatracker.ietf.org/doc/html/rfc3986 %23section-3.1___.YXAzOmRpZ2ljZXJ0OmE6bzphMjkxNGFhMTM5NWViNDkzODQ2ZjUwY2YwNT gwNzE2ZDo2OjkyMTQ6ODgzZGM3YWUxYTk1ZjU1MDAzZDcxNWUzYWI4MWY2NjQ3NzAwYTI4NGYxM2 E3ZjViNjc3Yjk0NGJkMzE3YWZhZDp0OkY which defines those schemes. Taking this opportunity for a ballot, the group suggested going through the BRs and EVGs to make sure consistent language is used for HTTP/S "schemes" to avoid any unintended errors. Enrico agreed with the task. Martijn proposed adding "HTTP scheme" in the definitions section so it can be used throughout the document. Dimitris proposed re-using the terminology of RFC 3986, perhaps combined with a definition in section 1.6.1 which will make it even more clear. In terms of next steps, Enrico asked for some assistance to draft a ballot and will start from a new branch on GitHub. Many members volunteered to assist so Enrico can reach out to people for assistance with the process and GitHub. The same applies for Pedro. Adjourn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5231 bytes Desc: not available URL: From Corey.Bonnell at digicert.com Wed Jul 17 19:53:10 2024 From: Corey.Bonnell at digicert.com (Corey Bonnell) Date: Wed, 17 Jul 2024 19:53:10 +0000 Subject: [cabf_validation] 2024-07-25 validation-sc meeting cancelled Message-ID: Hello, Both Wayne and I will be unable to attend next week's call, so let's cancel for next week and pick up at our next scheduled meeting on August 8th. Thanks, Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5231 bytes Desc: not available URL: From tobij at opera.com Thu Jul 18 16:27:30 2024 From: tobij at opera.com (Tobias S. Josefowitz) Date: Thu, 18 Jul 2024 18:27:30 +0200 (CEST) Subject: [cabf_validation] Using dedicated DNS resolvers for domain validation In-Reply-To: <01000190b66f85f0-b18778dd-795d-465d-917f-6248fa619601-000000@email.amazonses.com> References: <01000190b66f85f0-b18778dd-795d-465d-917f-6248fa619601-000000@email.amazonses.com> Message-ID: <303bd335-5937-db27-87cf-b72f9208d0d2@opera.com> Hi Doug, On Mon, 15 Jul 2024, Doug Beattie via Validation wrote: > During the last VWG call we had a good technical discussion on security > concerns related to DNS resolvers being used for multiple purposes. > There was agreement that CAs need to use a dedicated DNS resolver for > domain validation even if we didn't reach agreement on being permitted > to use a third party resolver. > > I'm curious what the scope of "domain validation" means in this regard. > Can CAs use the same resolver for CAA, posting certificates to CT logs, > doing who-is or RDAP queries, and if not, then maybe we should list more > specifically what we mean by "Dedicated resolver for Domain Validation" > when it comes to this locked down resolver topic? I'd like to start by stating that my comments regarding the use of DNS in DV during that call were mostly about the goal and purpose of DV, the functional properties of the DNS protocol, associated risks and security threats. I was outlining what I would expect an implementation of a DV process to look like; it was not necessarily a comment about what is currently required by the BRs or NCSSRs or anything else. To summarize my perspective, the DNS protocol has inherent weaknesses that threaten the authenticity of DNS responses/results. For example, DNS was initially designed to be a UDP-based protocol, and the only security measure against spoofed responses was a two-byte request ID field that would be populated with a random value (one of 65536 possible). While the protocol has been extended to be defined over TCP as well, UDP is usually preferred by resolvers for performance. The current security baseline for UDP-based DNS requests is less than 4 byte of randomness protecting the resolver from spoofed responses (some of you may remember that Dan Kaminsky drew attention to the fact that DNS is only protected by two bytes in 2008, and coordinated an industry-wide push to include source port randomization in DNS queries to increase randomness to a bit less than four bytes - some of you may even be aware that Dan "djb" Bernstein has pointed this out much before Kaminsky but has been widely ignored). These weaknesses have often been the basis for off-path attacks against DNS. If we for simplicity assume two bytes of "security", you can see that even if your random value is hardcoded to "0xff", you will succeed in spoofing 1 out of 65536 requests in so far as you manage to always send your forged response after the resolver sent the query but before it receives the authoritative nameserver's response. Thus it is obviously immediately beneficial for an attacker if they can cause the resolver to make many requests, giving the atacker more chances to get the resolver to accept a forged response. Both the DNS protocol and DNS resolver implementations have received further hardening against such attacks, for example the DNS COOKIE mechanism extension to the protocol and DNSSEC, as well as hardening against so called sibling attacks in implementations. These are good measures, but as we know DNSSEC rollout is minimal when it comes to protected domains, and DNS COOKIE is an optional extension that attackers could even run downgrade attacks against. Considering that at its core, DNS is still (usually) a DNS based protocol with less than four bytes of security, I would expect that anyone trying to use it for Domain Validation would conclude that DV requires special considerations when it comes to the use of DNS. When I think about it, immediate conclusions are: * It must not be possible for attackers to issue requests to the DNS resolver used, except as mitigated by the DV process to what is absolutely necessary and at a moderated volume/maximum frequency. * The resolver should probably try to query via TCP by default, and only fall back to UDP when querying via TCP is not supported by the authoritative nameserver that is being queried. These two points are critical considerations, but they are by no means exhaustive. When actually impementing a "DV resolver", I would expect more topics to come up and be considered, ranging from looking at the configuration options and establishing what are good settings for the DV use case, as well as the question of whether DNS protocol-level attacks (attempts) against the "DV resolver" should be detected and cause validation to fail or lead to other, more advanced or refined measures to ensure correctness of the validation. I put the second point as a "should probably" because I have not tried this in any real-world application and cannot with absolute confidence, ascertain how many problems this would cause. I hope none to very few if done properly. These two points immediately preclude any kind of public resolver from being used, because they indeed accept all kinds of queries from potential attackers and are configured to provide DNS results quickly (i.e. they prefer UDP over DNS). I would wager that there is no third party service currently offered by anyone that would fit these criteria. Looking at the two points given above, I would further conclude that using the "DV resolver" for figuring out how to reach whois/RDAP and CT logs ranges anywhere from "not conflicting" to "probably a good idea", likely closer to the latter. Tobi From aaron at letsencrypt.org Thu Jul 18 17:21:58 2024 From: aaron at letsencrypt.org (Aaron Gable) Date: Thu, 18 Jul 2024 10:21:58 -0700 Subject: [cabf_validation] Using dedicated DNS resolvers for domain validation In-Reply-To: <01000190c6abae9e-68e4bea9-fb4a-4328-97cc-4b6d11377cf7-000000@email.amazonses.com> References: <01000190b66f85f0-b18778dd-795d-465d-917f-6248fa619601-000000@email.amazonses.com> <01000190c6abae9e-68e4bea9-fb4a-4328-97cc-4b6d11377cf7-000000@email.amazonses.com> Message-ID: For the sake of raising awareness, I will add a third measure which CA dedicated DNS resolvers can take to mitigate the various failure modes of DNS and public DNS resolvers: - Implement RFC 9539 "Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS", meaning that their dedicated recursive resolver will use DNS-over-TLS / DNS-over-QUIC when querying authoritative nameservers which support those protocols. Aaron On Thu, Jul 18, 2024 at 9:27?AM Tobias S. Josefowitz via Validation < validation at cabforum.org> wrote: > Hi Doug, > > On Mon, 15 Jul 2024, Doug Beattie via Validation wrote: > > > During the last VWG call we had a good technical discussion on security > > concerns related to DNS resolvers being used for multiple purposes. > > There was agreement that CAs need to use a dedicated DNS resolver for > > domain validation even if we didn't reach agreement on being permitted > > to use a third party resolver. > > > > I'm curious what the scope of "domain validation" means in this regard. > > Can CAs use the same resolver for CAA, posting certificates to CT logs, > > doing who-is or RDAP queries, and if not, then maybe we should list more > > specifically what we mean by "Dedicated resolver for Domain Validation" > > when it comes to this locked down resolver topic? > > I'd like to start by stating that my comments regarding the use of DNS in > DV during that call were mostly about the goal and purpose of DV, the > functional properties of the DNS protocol, associated risks and > security threats. I was outlining what I would expect an implementation of > a DV process to look like; it was not necessarily a comment about what is > currently required by the BRs or NCSSRs or anything else. > > To summarize my perspective, the DNS protocol has inherent weaknesses that > threaten the authenticity of DNS responses/results. For example, DNS was > initially designed to be a UDP-based protocol, and the only security > measure against spoofed responses was a two-byte request ID field that > would be populated with a random value (one of 65536 possible). > > While the protocol has been extended to be defined over TCP as well, UDP > is usually preferred by resolvers for performance. The current security > baseline for UDP-based DNS requests is less than 4 byte of randomness > protecting the resolver from spoofed responses (some of you may remember > that Dan Kaminsky drew attention to the fact that DNS is only protected by > two bytes in 2008, and coordinated an industry-wide push to include source > port randomization in DNS queries to increase randomness to a bit less > than four bytes - some of you may even be aware that Dan "djb" Bernstein > has pointed this out much before Kaminsky but has been widely ignored). > > These weaknesses have often been the basis for off-path attacks against > DNS. If we for simplicity assume two bytes of "security", you can see that > even if your random value is hardcoded to "0xff", you will succeed in > spoofing 1 out of 65536 requests in so far as you manage to always send > your forged response after the resolver sent the query but before it > receives the authoritative nameserver's response. Thus it is obviously > immediately beneficial for an attacker if they can cause the resolver to > make many requests, giving the atacker more chances to get the resolver to > accept a forged response. > > Both the DNS protocol and DNS resolver implementations have received > further hardening against such attacks, for example the DNS COOKIE > mechanism extension to the protocol and DNSSEC, as well as hardening > against so called sibling attacks in implementations. These are good > measures, but as we know DNSSEC rollout is minimal when it comes to > protected domains, and DNS COOKIE is an optional extension that attackers > could even run downgrade attacks against. > > Considering that at its core, DNS is still (usually) a DNS based protocol > with less than four bytes of security, I would expect that anyone trying > to use it for Domain Validation would conclude that DV requires special > considerations when it comes to the use of DNS. > > When I think about it, immediate conclusions are: > > * It must not be possible for attackers to issue requests to the DNS > resolver used, except as mitigated by the DV process to what is > absolutely necessary and at a moderated volume/maximum frequency. > * The resolver should probably try to query via TCP by default, and only > fall back to UDP when querying via TCP is not supported by the > authoritative nameserver that is being queried. > > These two points are critical considerations, but they are by no means > exhaustive. When actually impementing a "DV resolver", I would expect more > topics to come up and be considered, ranging from looking at the > configuration options and establishing what are good settings for the DV > use case, as well as the question of whether DNS protocol-level attacks > (attempts) against the "DV resolver" should be detected and cause > validation to fail or lead to other, more advanced or refined measures to > ensure correctness of the validation. > > I put the second point as a "should probably" because I have not tried > this in any real-world application and cannot with absolute confidence, > ascertain how many problems this would cause. I hope none to very few if > done properly. > > These two points immediately preclude any kind of public resolver from > being used, because they indeed accept all kinds of queries from potential > attackers and are configured to provide DNS results quickly (i.e. they > prefer UDP over DNS). I would wager that there is no third party service > currently offered by anyone that would fit these criteria. > > Looking at the two points given above, I would further conclude that using > the "DV resolver" for figuring out how to reach whois/RDAP and CT logs > ranges anywhere from "not conflicting" to "probably a good idea", likely > closer to the latter. > > Tobi > _______________________________________________ > Validation mailing list > Validation at cabforum.org > https://lists.cabforum.org/mailman/listinfo/validation > -------------- next part -------------- An HTML attachment was scrubbed... URL: