Re: DRAFT January 2018 CA Communication
I've opened bugs for the following CAs that still haven't responded: - GoDaddy - Certinomis / Docapost - Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe) - TurkTrust - E-Tugra You can find these bugs on the Incident Dashboard: https://wiki.mozilla.org/CA/Incident_Dashboard - Wayne On Mon, Feb 12, 2018 at 11:11 AM, Wayne Thayerwrote: > Friday was the deadline for responding to this survey. Responses are now > published at https://wiki.mozilla.org/CA/Communications#January_2018_ > Responses > > I would like to thank everyone who took the time to respond, and > especially those who provided detailed answers to Action 2 regarding > methods 1 and 5. > > The following CAs have not responded: > >- Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) >- GoDaddy >- Disig, a.s. >- Certinomis / Docapost >- Cybertrust Japan / JCSI >- Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe) >- TurkTrust >- Web.com >- E-Tugra > > I will allow a grace period of a few days and then will open incident bugs > for those CAs that still haven't responded. > > - Wayne > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT January 2018 CA Communication
Friday was the deadline for responding to this survey. Responses are now published at https://wiki.mozilla.org/CA/Communications#January_2018_Responses I would like to thank everyone who took the time to respond, and especially those who provided detailed answers to Action 2 regarding methods 1 and 5. The following CAs have not responded: - Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) - GoDaddy - Disig, a.s. - Certinomis / Docapost - Cybertrust Japan / JCSI - Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe) - TurkTrust - Web.com - E-Tugra I will allow a grace period of a few days and then will open incident bugs for those CAs that still haven't responded. - Wayne On Mon, Jan 29, 2018 at 5:14 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > The email has been sent, and we've published a blog post: > > https://blog.mozilla.org/security/2018/01/29/january-2018-ca > -communication/ > > On Monday, January 29, 2018 at 1:15:51 PM UTC-7, Wayne Thayer wrote: > > You can find a link to the final version of the survey at > > https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication > > > > We're planning to send this out to all CAs in the Mozilla program later > > today. The deadline for responses has been set to 9-February. > > > > Thanks to everyone who contributed to this effort. > > > > - Wayne > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT January 2018 CA Communication
The email has been sent, and we've published a blog post: https://blog.mozilla.org/security/2018/01/29/january-2018-ca-communication/ On Monday, January 29, 2018 at 1:15:51 PM UTC-7, Wayne Thayer wrote: > You can find a link to the final version of the survey at > https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication > > We're planning to send this out to all CAs in the Mozilla program later > today. The deadline for responses has been set to 9-February. > > Thanks to everyone who contributed to this effort. > > - Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT January 2018 CA Communication
You can find a link to the final version of the survey at https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication We're planning to send this out to all CAs in the Mozilla program later today. The deadline for responses has been set to 9-February. Thanks to everyone who contributed to this effort. - Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT January 2018 CA Communication
Thanks Jakob. I updated the draft as described below. On Fri, Jan 26, 2018 at 10:42 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I think a number of the questions/actions need additional options: > > For ACTION 1: > > (These 3 are between the 1st and second current option). > > Add Option: Our CPS permits these methods, but we have already stopped > exercising that permission, and any certificates so issued are no > longer valid (expired or revoked). > > Add Option: We previously used these methods, but have already suspended > doing so, We have reviewed our past implementation for vulnerabilities > and have reported our findings below. > > Add option: We previously used these methods, but have already suspended > doing so, We will review our past implementation for vulnerabilities > and report our findings on the mozilla.dev.security.policy list by the > date specified in the comments section below. > > I don't think many CAs are using these methods, so I simplified your suggestion by changing option 3 to "Other (please describe below)" > > For ACTION 2: > > Add option: Our CPS permits these methods, but we only use them in a way > that already complies with the proposed method 12 in CAB/F ballot 218. > > Added. Plus the 3 extra options from ACTION 1 > > I again tried to simplify your suggestion by changing the existing choices to cover these cases. > For ACTION 4: > > Split the second item into: > > Option: We intend to deliver our BR Self Assessment prior to 31-january > 2018 > > Option: We previously requested an extension and intend to deliver our > BR Self Assessment prior to 15-April 2018. > > Done. For ACTION 5: > > Split the or clause into two options (formatting error) > > Fixed. For ACTION 6: > > Split into 3 options > > Option: We have never issued SSL certificates with a validity period > greater than 825 days, and will not do so in the future. > > Option: We will stop issueing SSL certificates with a validity period > greater than 825 days on or before 1-March 2018 > > Option: We will stop issueing SSL certificates with a validity period > greater than 825 days on or before 1-March 2018. Some certificates > issued before 1-March 2018 have a not-before date after 28-Feb 2018 > and more than 825 days before their not-after date. (But not-after is > still less than the previously permitted maximum time after the date > of issuance). > > (That 3rd option would apply, at least, to GlobalSign according to > another thread). > > I rejected this change because it was determined that GlobalSign didn't break any rules or find a loophole that bypasses the new 825-day requirement, and the intent of this action is not to discover which CAs have been issuing 3-year certs. > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT January 2018 CA Communication
On 26/01/2018 18:11, Wayne Thayer wrote: Based on the feedback we've received, but sticking with the original intent of this communication, I have converted it into a survey. You can find a draft at: https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication I would appreciate your comments on this. I have set the deadline for responses to 9-Feb, making the assumption that we can send this out on Monday. I think a number of the questions/actions need additional options: For ACTION 1: (These 3 are between the 1st and second current option). Add Option: Our CPS permits these methods, but we have already stopped exercising that permission, and any certificates so issued are no longer valid (expired or revoked). Add Option: We previously used these methods, but have already suspended doing so, We have reviewed our past implementation for vulnerabilities and have reported our findings below. Add option: We previously used these methods, but have already suspended doing so, We will review our past implementation for vulnerabilities and report our findings on the mozilla.dev.security.policy list by the date specified in the comments section below. For ACTION 2: Add option: Our CPS permits these methods, but we only use them in a way that already complies with the proposed method 12 in CAB/F ballot 218. Plus the 3 extra options from ACTION 1 For ACTION 4: Split the second item into: Option: We intend to deliver our BR Self Assessment prior to 31-january 2018 Option: We previously requested an extension and intend to deliver our BR Self Assessment prior to 15-April 2018. For ACTION 5: Split the or clause into two options (formatting error) For ACTION 6: Split into 3 options Option: We have never issued SSL certificates with a validity period greater than 825 days, and will not do so in the future. Option: We will stop issueing SSL certificates with a validity period greater than 825 days on or before 1-March 2018 Option: We will stop issueing SSL certificates with a validity period greater than 825 days on or before 1-March 2018. Some certificates issued before 1-March 2018 have a not-before date after 28-Feb 2018 and more than 825 days before their not-after date. (But not-after is still less than the previously permitted maximum time after the date of issuance). (That 3rd option would apply, at least, to GlobalSign according to another thread). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT January 2018 CA Communication
Based on the feedback we've received, but sticking with the original intent of this communication, I have converted it into a survey. You can find a draft at: https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication I would appreciate your comments on this. I have set the deadline for responses to 9-Feb, making the assumption that we can send this out on Monday. Thanks, Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT January 2018 CA Communication
On Fri, Jan 26, 2018 at 5:24 AM Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 24/01/18 22:19, Jonathan Rudenberg wrote: > > While these CAs might want six months, it’s not clear that a good > > argument has been made for this. Let’s Encrypt stopped validating > > using the TLS-SNI-01 method under two hours after learning that there > > was a *potential* security vulnerability in the validation method. > > Why should we expect any less from other CAs? We should err on the > > side of protecting users, not CAs using insecure validation methods > > that don’t even stand up to a small amount of adversarial scrutiny. > > Six months may or many not be the right timeline, but I don't think it's > fair to compare removing an option in an automated process (which was, > in fact, subsequently restored for existing customers within a few days) > with retraining all your validation specialists to use a different > manual process. Such work cannot be done in 2 hours. As you noted in the CA/Browser Forum, and other CAs have, the only real change from a .1 to a .2/.3 is that the CA calls the domain contact from WHOIS, rather than a phone number they got from a “reliable source” (3.2.5). We should be careful not to accept the unsubstantiated and questionable narrative of CAs view of difficulty. If anything, automation is harder to replace because you have an ecosystem to uplift - new protocols and new upgrades - whereas as you note, even a radical change in issuance practice can be accomplished via simple training of a limited number of validation specialists. The economies of scale of that transition highly favor rapid transition from manual validation methods. > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT January 2018 CA Communication
On 24/01/18 22:19, Jonathan Rudenberg wrote: > While these CAs might want six months, it’s not clear that a good > argument has been made for this. Let’s Encrypt stopped validating > using the TLS-SNI-01 method under two hours after learning that there > was a *potential* security vulnerability in the validation method. > Why should we expect any less from other CAs? We should err on the > side of protecting users, not CAs using insecure validation methods > that don’t even stand up to a small amount of adversarial scrutiny. Six months may or many not be the right timeline, but I don't think it's fair to compare removing an option in an automated process (which was, in fact, subsequently restored for existing customers within a few days) with retraining all your validation specialists to use a different manual process. Such work cannot be done in 2 hours. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT January 2018 CA Communication
On Thu, Jan 25, 2018 at 4:20 PM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thu, Jan 25, 2018 at 1:02 PM, Ryan Sleevi via dev-security-policy >wrote: > > On Thu, Jan 25, 2018 at 3:34 PM, Wayne Thayer > wrote: > > > >> On Thu, Jan 25, 2018 at 11:48 AM, Jonathan Rudenberg < > >> jonat...@titanous.com> wrote: > >> > >>> This is a great improvement. I think we should also ask that any CAs > >>> using these methods immediate disclose that they are and the procedures > >>> they are using, as well as the date they expect to complete a review of > >>> their implementation, and then provide the review when it is complete. > >> > >> > >> The scope of this issue is much different from the method .9 and .10 > >> vulnerabilities - lot of CAs use methods .1 and .5. Asking them all to > >> answer these questions seems likely to just yield a bunch of "we > reviewed > >> our implementation and it is perfect" emails. What do you hope to learn > >> from this disclosure that hasn't already been discussed? What do others > >> think? > >> > >> If we want to hold CAs accountable for this disclosure, we'll need to > turn > >> this communication into a survey and give CAs a certain amount of time > to > >> respond, so we won't have answers for weeks. > >> > > > > I'm curious why the "for weeks" disclosure. > > > > Mozilla has required since April 2017 that CAs disclose the method of > > validation they use - https://wiki.mozilla.org/CA/ > Communications#April_2017 > > (Specifically, Action #1), which MUST be completed before July 21, 2017. > > > > Jonathan's proposal to require the CAs "immediately disclose that they > are" > > is thus consistent with the CA simply reading its CP/CPS. Further, "the > > procedures that they are using" is also a matter of existing CP/CPS > > documentation and/or supporting documents - making them explicitly > public. > > > > So this merely leaves the question of "The date they expect to complete a > > review of their implementation, and then provide the review when it is > > complete". > > What incentive is there for a CA to ever answer with anything other than: > > a) that they may use any method allowed by Mozilla, and > > b) they have reviewed their implementation and believe that it > complies with Mozilla's requirements? > I'm not sure I follow - there's two different things at play here. Combining Wayne's text with Jonathan's proposal, the question is to require CAs disclose whether they're specifically using 3.2.2.4.1 and 3.2.2.4.5. If they are, additional work is asked of them. If they aren't, their work is done. Thus the incentive for the CA is to be precise about what methods they are using, because if they aren't using those methods, then there's no work for them to do. The Baseline Requirements already require - using a specific proposal from Mozilla - that CAs "SHALL maintain a record of which domain validation method, including relevant BR version number, they used to validate every domain." So every CA already has the information available as to - What methods they COULD use to validate - What methods they DO use to validate And the request is that they simply aggregate and provide that information as part of a normal disclosure process, for information that should be readily available, in order to inform policy and the potential risks of changing policy, both per-CA and per the ecosystem. A more concrete question may be: - Does your CP/CPS permit you to use 3.2.2.4.1? - Does your CP/CPS permit you to use 3.2.2.4.5? - If you answered yes to either of the previous two questions: - In the past 6 months, how many certificates did you issue? - In the past 6 months, how many certificates did you issue that contained a domain validated using 3.2.2.4.1 - In the past 6 months, how many new domain validations using 3.2.2.4.1 were performed - In the past 6 months, how many unique domains reused a previously completed 3.2.2.4.1 validation - In the past 6 months, how many certificates did you issue that contained a domain validated using 3.2.2.4.5 - In the past 6 months, how many new domain validations using 3.2.2.4.5 were performed - In the past 6 months, how many unique domains reused a previously completed 3.2.2.4.5 validation The first two questions involve reviewing the CP/CPS. The CA should be qualified to so. The remaining questions 'should' be simple queries on their issuance database. A CA that has not maintained accessible records of such issuance - for example, putting them in a locked filing cabinet, in the basement, beneath the leopard - is a CA not equipped to effectively respond to security risks. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT January 2018 CA Communication
On Thu, Jan 25, 2018 at 3:34 PM, Wayne Thayerwrote: > On Thu, Jan 25, 2018 at 11:48 AM, Jonathan Rudenberg < > jonat...@titanous.com> wrote: > >> This is a great improvement. I think we should also ask that any CAs >> using these methods immediate disclose that they are and the procedures >> they are using, as well as the date they expect to complete a review of >> their implementation, and then provide the review when it is complete. > > > The scope of this issue is much different from the method .9 and .10 > vulnerabilities - lot of CAs use methods .1 and .5. Asking them all to > answer these questions seems likely to just yield a bunch of "we reviewed > our implementation and it is perfect" emails. What do you hope to learn > from this disclosure that hasn't already been discussed? What do others > think? > > If we want to hold CAs accountable for this disclosure, we'll need to turn > this communication into a survey and give CAs a certain amount of time to > respond, so we won't have answers for weeks. > I'm curious why the "for weeks" disclosure. Mozilla has required since April 2017 that CAs disclose the method of validation they use - https://wiki.mozilla.org/CA/Communications#April_2017 (Specifically, Action #1), which MUST be completed before July 21, 2017. Jonathan's proposal to require the CAs "immediately disclose that they are" is thus consistent with the CA simply reading its CP/CPS. Further, "the procedures that they are using" is also a matter of existing CP/CPS documentation and/or supporting documents - making them explicitly public. So this merely leaves the question of "The date they expect to complete a review of their implementation, and then provide the review when it is complete". When faced with potential Security Vulnerabilities, Mozilla has required prompt disclosure - see, for example, https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication and https://wiki.mozilla.org/CA/Communications#September_2011 The question, then, is how long it should take CAs to: - Receive a communication from Mozilla - Read their CP/CPS and issuance practices - Reply to two questions: - Are you using these methods? - When will you expect to have your review? Given that both GlobalSign and Let's Encrypt were able to identify within days, it seems like the upper-bound for a response - and a completed review - should be suitable within a week, at the absolute most. Any CA who cannot respond and review that quickly raises questions about their ability to be trusted ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT January 2018 CA Communication
On Thu, Jan 25, 2018 at 11:48 AM, Jonathan Rudenbergwrote: > This is a great improvement. I think we should also ask that any CAs using > these methods immediate disclose that they are and the procedures they are > using, as well as the date they expect to complete a review of their > implementation, and then provide the review when it is complete. The scope of this issue is much different from the method .9 and .10 vulnerabilities - lot of CAs use methods .1 and .5. Asking them all to answer these questions seems likely to just yield a bunch of "we reviewed our implementation and it is perfect" emails. What do you hope to learn from this disclosure that hasn't already been discussed? What do others think? If we want to hold CAs accountable for this disclosure, we'll need to turn this communication into a survey and give CAs a certain amount of time to respond, so we won't have answers for weeks. - Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT January 2018 CA Communication
> On Jan 25, 2018, at 13:09, Wayne Thayer via dev-security-policy >wrote: > > Tim - I will add a reference to TLS-SNI-02 as you suggested. I think an > explanation of the new method 12 is too much detail for this message, and > it can be found in the ballot that I've referenced. > > In order to move ahead with this communication to CAs while our timeline > for the deprecation of BR 3.2.2.4 methods 1 and 5 is still being discussed, > I'd like to propose modifying item #2 as follows: > > 2. On 19-December, significant concerns were raised about the reliability > of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5. > [3] Since then, discussions on the CA/Browser Forum Public list have > resulted in a proposed ballot to prohibit the use of these methods after > 1-August 2018. [4] Rather than accept the risk of continued use of these > methods, Mozilla may decide to set an earlier deadline such as 1-March > 2018. If your CA uses either of these methods, please evaluate your > implementation for vulnerabilities, follow the discussion closely, and be > prepared to quickly discontinue your use of these methods of domain > validation. > > Please comment on this change. This is a great improvement. I think we should also ask that any CAs using these methods immediate disclose that they are and the procedures they are using, as well as the date they expect to complete a review of their implementation, and then provide the review when it is complete. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT January 2018 CA Communication
Tim - I will add a reference to TLS-SNI-02 as you suggested. I think an explanation of the new method 12 is too much detail for this message, and it can be found in the ballot that I've referenced. In order to move ahead with this communication to CAs while our timeline for the deprecation of BR 3.2.2.4 methods 1 and 5 is still being discussed, I'd like to propose modifying item #2 as follows: 2. On 19-December, significant concerns were raised about the reliability of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5. [3] Since then, discussions on the CA/Browser Forum Public list have resulted in a proposed ballot to prohibit the use of these methods after 1-August 2018. [4] Rather than accept the risk of continued use of these methods, Mozilla may decide to set an earlier deadline such as 1-March 2018. If your CA uses either of these methods, please evaluate your implementation for vulnerabilities, follow the discussion closely, and be prepared to quickly discontinue your use of these methods of domain validation. Please comment on this change. Thanks, Wayne On Wed, Jan 24, 2018 at 5:09 PM, Wayne Thayerwrote: > On Wed, Jan 24, 2018 at 4:05 PM, Ryan Sleevi wrote: > >> >> >> On Wed, Jan 24, 2018 at 5:05 PM, Wayne Thayer via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >>> >>> > Is there a reason to make this deprecation conditional on the ballot? >>> > Given what we know about how the vulnerable methods are used in the >>> wild, >>> > they have the same level of brokenness as TLS-SNI-01/02 and it’s not >>> clear >>> > how evaluating for vulnerabilities would fix anything. >>> >>> >>> This is a matter of timing. When possible, we should give the CA/Browser >>> Forum time to act before Mozilla does so unilaterally. Also, changing our >>> own policy is a process that would need to happen before we send this >>> communication. I have already suggested the Mozilla policy change [1]. >>> >> >> Why is this? >> >> Mozilla unilaterally acted with the 10 Blessed Methods in order to >> mitigate security risks, after the Forum kept postponing. >> > > Yes, *after the Forum kept postponing*. > > Google and Microsoft (and later Mozilla) unilaterally acted with the >> deprecation of SHA-1. >> > > My recollection is that Microsoft acted after first raising the issue with > the Forum and getting nowhere. So I believe that both of your examples > support my statement. > >> >> The CA/Browser Forum consensus process does not produce results aligned >> with the Mozilla Foundation Manifesto, per-se, as it reflects a consensus >> process where 2/3 of CAs have agreed to do something. This naturally >> creates a situation of regulatory capture unaligned with the interests of >> or security of Mozilla users. >> >> There's two parts to the question at play here: >> 1) Does Mozilla believe the ballot is likely to pass the Forum, given a >> number of CA's stated opposition? >> > > I can't answer that, but it does appear logical that the ballot is less > likely to succeed with a March deadline. > > >> 2) Does Mozilla believe August is an appropriate time to cease the >> practice, given the risks? >> > > I don't know if there is consensus on this, but it is now clear to me that > at least some members of our community believe that August is not > appropriate. > > - Similarly, is Mozilla comfortable with accepting certificates using >> methods with disclosed vulnerabilities between now and that time, and that >> CAs sufficiently understand said vulnerabilities and have devised (but >> seemingly not yet disclosed) appropriate mitigations or controls? >> >> > Based on the feedback we've seen on this list, I'm going to say no, this > is a risk we're not comfortable with. > > >> We could still choose to set that date in our own policy if the ballot >>> were >>> to fail. The reasoning behind that date has been discussed on the >>> CA/Browser Forum lists. >> >> >> Are you talking the public list, or some other list, such as the >> Validation WG list? As a co-endorser of the Ballot, in its current form of >> August, it was presented that unless we agreed to endorse at August, it was >> not worth putting forward. One reason privately put forward as to why >> August was because "other user agents" would vote against it unless it was >> August. Is Mozilla such a User Agent? >> >> I expressed my concerns about a Mar 1 deadline on a Validation WG call > and then reiterated them on the Public list: > https://cabforum.org/pipermail/public/2018-January/012713.html I don't > think that message suggests Mozilla would vote against an earlier deadline, > and I can't say if Mozilla would or not. Conversely, your endorsement of > the ballot certainly made me think that Google supported the August > deadline. > > >> I'm not yet aware of conversation that speaks to the volume of its usage >> (those questions have gone unanswered) or to the challenges in migrating
Re: DRAFT January 2018 CA Communication
On Wed, Jan 24, 2018 at 4:05 PM, Ryan Sleeviwrote: > > > On Wed, Jan 24, 2018 at 5:05 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: >> >> > Is there a reason to make this deprecation conditional on the ballot? >> > Given what we know about how the vulnerable methods are used in the >> wild, >> > they have the same level of brokenness as TLS-SNI-01/02 and it’s not >> clear >> > how evaluating for vulnerabilities would fix anything. >> >> >> This is a matter of timing. When possible, we should give the CA/Browser >> Forum time to act before Mozilla does so unilaterally. Also, changing our >> own policy is a process that would need to happen before we send this >> communication. I have already suggested the Mozilla policy change [1]. >> > > Why is this? > > Mozilla unilaterally acted with the 10 Blessed Methods in order to > mitigate security risks, after the Forum kept postponing. > Yes, *after the Forum kept postponing*. Google and Microsoft (and later Mozilla) unilaterally acted with the > deprecation of SHA-1. > My recollection is that Microsoft acted after first raising the issue with the Forum and getting nowhere. So I believe that both of your examples support my statement. > > The CA/Browser Forum consensus process does not produce results aligned > with the Mozilla Foundation Manifesto, per-se, as it reflects a consensus > process where 2/3 of CAs have agreed to do something. This naturally > creates a situation of regulatory capture unaligned with the interests of > or security of Mozilla users. > > There's two parts to the question at play here: > 1) Does Mozilla believe the ballot is likely to pass the Forum, given a > number of CA's stated opposition? > I can't answer that, but it does appear logical that the ballot is less likely to succeed with a March deadline. > 2) Does Mozilla believe August is an appropriate time to cease the > practice, given the risks? > I don't know if there is consensus on this, but it is now clear to me that at least some members of our community believe that August is not appropriate. - Similarly, is Mozilla comfortable with accepting certificates using > methods with disclosed vulnerabilities between now and that time, and that > CAs sufficiently understand said vulnerabilities and have devised (but > seemingly not yet disclosed) appropriate mitigations or controls? > > Based on the feedback we've seen on this list, I'm going to say no, this is a risk we're not comfortable with. > We could still choose to set that date in our own policy if the ballot were >> to fail. The reasoning behind that date has been discussed on the >> CA/Browser Forum lists. > > > Are you talking the public list, or some other list, such as the > Validation WG list? As a co-endorser of the Ballot, in its current form of > August, it was presented that unless we agreed to endorse at August, it was > not worth putting forward. One reason privately put forward as to why > August was because "other user agents" would vote against it unless it was > August. Is Mozilla such a User Agent? > > I expressed my concerns about a Mar 1 deadline on a Validation WG call and then reiterated them on the Public list: https://cabforum.org/ pipermail/public/2018-January/012713.html I don't think that message suggests Mozilla would vote against an earlier deadline, and I can't say if Mozilla would or not. Conversely, your endorsement of the ballot certainly made me think that Google supported the August deadline. > I'm not yet aware of conversation that speaks to the volume of its usage > (those questions have gone unanswered) or to the challenges in migrating to > an alternative method (such as .2 or .3), which are still remarkably > flexible and, indeed, mitigations for the risk of .1 inevitably come back > to being .2 or .3 methods. > > >> I would summarize the argument as (1) a number of >> smaller CAs rely solely on 3.2.2.4.1 and (2) those that have commented >> agreed that 6 months was enough time to migrate away from it. >> > > I've not seen any CA publicly state that 6 months was sufficient time. Was > this on the Validation list? > Yes - https://cabforum.org/pipermail/validation/2018-January/000703.html ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT January 2018 CA Communication
On Wed, Jan 24, 2018 at 5:05 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > Is there a reason to make this deprecation conditional on the ballot? > > Given what we know about how the vulnerable methods are used in the wild, > > they have the same level of brokenness as TLS-SNI-01/02 and it’s not > clear > > how evaluating for vulnerabilities would fix anything. > > > This is a matter of timing. When possible, we should give the CA/Browser > Forum time to act before Mozilla does so unilaterally. Also, changing our > own policy is a process that would need to happen before we send this > communication. I have already suggested the Mozilla policy change [1]. > Why is this? Mozilla unilaterally acted with the 10 Blessed Methods in order to mitigate security risks, after the Forum kept postponing. Google and Microsoft (and later Mozilla) unilaterally acted with the deprecation of SHA-1. The CA/Browser Forum consensus process does not produce results aligned with the Mozilla Foundation Manifesto, per-se, as it reflects a consensus process where 2/3 of CAs have agreed to do something. This naturally creates a situation of regulatory capture unaligned with the interests of or security of Mozilla users. There's two parts to the question at play here: 1) Does Mozilla believe the ballot is likely to pass the Forum, given a number of CA's stated opposition? 2) Does Mozilla believe August is an appropriate time to cease the practice, given the risks? - Similarly, is Mozilla comfortable with accepting certificates using methods with disclosed vulnerabilities between now and that time, and that CAs sufficiently understand said vulnerabilities and have devised (but seemingly not yet disclosed) appropriate mitigations or controls? > We could still choose to set that date in our own policy if the ballot were > to fail. The reasoning behind that date has been discussed on the > CA/Browser Forum lists. Are you talking the public list, or some other list, such as the Validation WG list? As a co-endorser of the Ballot, in its current form of August, it was presented that unless we agreed to endorse at August, it was not worth putting forward. One reason privately put forward as to why August was because "other user agents" would vote against it unless it was August. Is Mozilla such a User Agent? I'm not yet aware of conversation that speaks to the volume of its usage (those questions have gone unanswered) or to the challenges in migrating to an alternative method (such as .2 or .3), which are still remarkably flexible and, indeed, mitigations for the risk of .1 inevitably come back to being .2 or .3 methods. > I would summarize the argument as (1) a number of > smaller CAs rely solely on 3.2.2.4.1 and (2) those that have commented > agreed that 6 months was enough time to migrate away from it. > I've not seen any CA publicly state that 6 months was sufficient time. Was this on the Validation list? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT January 2018 CA Communication
> On Jan 24, 2018, at 17:05, Wayne Thayer via dev-security-policy >wrote: > > We could still choose to set that date in our own policy if the ballot were > to fail. The reasoning behind that date has been discussed on the > CA/Browser Forum lists. I would summarize the argument as (1) a number of > smaller CAs rely solely on 3.2.2.4.1 and (2) those that have commented > agreed that 6 months was enough time to migrate away from it. While these CAs might want six months, it’s not clear that a good argument has been made for this. Let’s Encrypt stopped validating using the TLS-SNI-01 method under two hours after learning that there was a *potential* security vulnerability in the validation method. Why should we expect any less from other CAs? We should err on the side of protecting users, not CAs using insecure validation methods that don’t even stand up to a small amount of adversarial scrutiny. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT January 2018 CA Communication
On Wed, Jan 24, 2018 at 1:50 PM, Jonathan Rudenbergwrote: > > > On Jan 24, 2018, at 15:20, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > 2. On 19-December, significant concerns were raised about the reliability > > of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5. > > [3] Since then, discussions on the CA/Browser Forum Public list have > > resulted in a proposed ballot to prohibit the use of these methods after > > 1-August 2018. [4] If your CA uses either of these methods, please > evaluate > > your implementation for vulnerabilities and be prepared to discontinue > > their use prior to the deadline if ballot 218 succeeds. > > Is there a reason to make this deprecation conditional on the ballot? > Given what we know about how the vulnerable methods are used in the wild, > they have the same level of brokenness as TLS-SNI-01/02 and it’s not clear > how evaluating for vulnerabilities would fix anything. This is a matter of timing. When possible, we should give the CA/Browser Forum time to act before Mozilla does so unilaterally. Also, changing our own policy is a process that would need to happen before we send this communication. I have already suggested the Mozilla policy change [1]. August is a long time from now, and even that date would be conditional on > the ballot. > We could still choose to set that date in our own policy if the ballot were to fail. The reasoning behind that date has been discussed on the CA/Browser Forum lists. I would summarize the argument as (1) a number of smaller CAs rely solely on 3.2.2.4.1 and (2) those that have commented agreed that 6 months was enough time to migrate away from it. > > I strongly believe that requiring CAs to disclose their use of these > methods immediately, and setting a date not more than a couple months from > now where these methods and previous validations using them must not be > used would be the correct choice to protect Mozilla’s users. > > Jonathan [1] https://github.com/mozilla/pkipolicy/issues/116 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT January 2018 CA Communication
> On Jan 24, 2018, at 15:20, Wayne Thayer via dev-security-policy >wrote: > > 2. On 19-December, significant concerns were raised about the reliability > of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5. > [3] Since then, discussions on the CA/Browser Forum Public list have > resulted in a proposed ballot to prohibit the use of these methods after > 1-August 2018. [4] If your CA uses either of these methods, please evaluate > your implementation for vulnerabilities and be prepared to discontinue > their use prior to the deadline if ballot 218 succeeds. Is there a reason to make this deprecation conditional on the ballot? Given what we know about how the vulnerable methods are used in the wild, they have the same level of brokenness as TLS-SNI-01/02 and it’s not clear how evaluating for vulnerabilities would fix anything. August is a long time from now, and even that date would be conditional on the ballot. I strongly believe that requiring CAs to disclose their use of these methods immediately, and setting a date not more than a couple months from now where these methods and previous validations using them must not be used would be the correct choice to protect Mozilla’s users. Jonathan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: DRAFT January 2018 CA Communication
Wayne, You might want to highlight that method 1 sub-method 3 would survive even if ballot 218 passes, as a new method 12 with some changes and improvements that CAs who use sub-method 3 should pay close attention to. With regards to TLS-SNI-01, I believe TLS-SNI-02 is also affected by the same issue and should be mentioned as well. -Tim smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
DRAFT January 2018 CA Communication
I want to directly notify all CAs in the Mozilla program of the recently exposed issues with domain validation methods and of some upcoming deadlines. A draft is available below and at https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication I would appreciate your prompt and constructive feedback on this message - I'd like to get it sent out this week. Thanks, Wayne === Dear Certification Authority, Because 2018 has already generated some important news for Certification Authorities, we are sending this message to ensure that every CA in the Mozilla program is aware of the following current events and impending deadlines: 1. On 9-January, the CA “Let’s Encrypt” disclosed a vulnerability in the ACME domain validation method known as TLS-SNI-01, which is an implementation of the more general method described in BR 3.2.2.4.10. [1] A subsequent vulnerability was disclosed on 11-January affecting the validation method described in BR 3.2.2.4.9. [2] Mozilla expects all CAs to be monitoring discussion in the mozilla.dev.security.policy forum and for any CA that employs either of these methods to disclose that fact on the list. From now on, Mozilla expects that CAs will not use these methods unless they have implemented and disclosed a mitigation for the vulnerabilities that have been discovered. 2. On 19-December, significant concerns were raised about the reliability of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5. [3] Since then, discussions on the CA/Browser Forum Public list have resulted in a proposed ballot to prohibit the use of these methods after 1-August 2018. [4] If your CA uses either of these methods, please evaluate your implementation for vulnerabilities and be prepared to discontinue their use prior to the deadline if ballot 218 succeeds. 3. Sections 5.3.1 and 5.3.2 of Mozilla Root Store Policy version 2.5 [5] require CAs to publicly disclose (via CCADB [6]) all subordinate CA certificates including those used to issue email S/MIME certificates by 15-January unless they are technically constrained to a whitelist of domains. We have since changed the compliance deadline to 15-April 2018. Certificate monitors have detected over 200 certificates that currently do not comply with this new policy. [7] Please ensure that your CA is in compliance before 15-April 2018. 4. In our November 2017 CA Communication [8], Mozilla asked all CAs with roots enabled for websites (SSL) to complete a BR self-assessment [9] by 31-January and send it to Kathleen. If you have not yet done so, please complete this work. If you requested an extension, your deadline is 15-April 2018. 5. If you are one of the CAs that indicated in your response to the November 2017 CA Communication that you need more time to update your CPS to comply with version 2.5 of the Mozilla Root Store Policy, please complete the updates no later than 15-April 2018. Mozilla feels that four months is more than long enough to make a CPS change. 6. On 17-March 2017, in ballot 193, the CA/Browser Forum set a deadline of 1-March 2018 after which newly-issued SSL certificates must not have a validity period greater than 825 days, and the re-use of validation information must be limited to 825 days. As with all other baseline requirements, Mozilla expects all CAs in the program to comply. Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit. Regards, Wayne Thayer Mozilla CA Program Manager [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/RHsIInIjJA0/LKrNi35aAQAJ [2] https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/PiOiGCyuxCU [3] https://cabforum.org/pipermail/public/2017-December/012630.html [4] https://cabforum.org/pipermail/public/2018-January/012819.html [5] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ [6] http://ccadb.org/cas/intermediates [7] https://groups.google.com/d/msg/mozilla.dev.security.policy/sKhPTsIYNqs/Q-_ZKmDVAQAJ [8] https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication [9] https://wiki.mozilla.org/CA/BR_Self-Assessment ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy