Re: DRAFT January 2018 CA Communication

[Ryan Sleevi via dev-security-policy]

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

[Ryan Sleevi via dev-security-policy]

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".

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

[Wayne Thayer via dev-security-policy]

On Thu, Jan 25, 2018 at 11:48 AM, Jonathan Rudenberg 
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.

- 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

[Jonathan Rudenberg via dev-security-policy]

> 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

[Wayne Thayer via dev-security-policy]

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  wrote:

> 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: GlobalSign certificate with far-future notBefore

[Gervase Markham via dev-security-policy]

On 24/01/18 18:02, Doug Beattie wrote:
> Can we consider this case closed with the action that the VWG will
> propose a ballot that addresses pre and postdating certificates?

Yes. I don't believe anyone has suggested that Globalsign broke a formal
rule, either in the BRs or Mozilla's requirements. Thank you for
engaging with us on this topic.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy