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 Thayer <wtha...@mozilla.com> wrote: > On Wed, Jan 24, 2018 at 4:05 PM, Ryan Sleevi <r...@sleevi.com> 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 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
