Policy 2.6 Proposal: Require CAs to support problem reports via email

[Wayne Thayer]

Section 4.9.3 of the CA/Browser Forum's Baseline Requirements says:
"The CA SHALL provide Subscribers, Relying Parties, Application Software
Suppliers, and other third parties with clear instructions for reporting
suspected Private Key Compromise, Certificate misuse, or other types of
fraud, compromise, misuse, inappropriate conduct, or any other matter
related to Certificates. The CA SHALL publicly disclose the instructions
through a readily accessible online means.”

Mozilla has made a central list of these mechanisms in the CCADB [1] but,
as it turns out, some of them (such as web forms with CAPTCHAs) are
difficult to use. It is proposed that Mozilla policy go above and beyond
the BR requirement to state that email must be one of the problem reporting
methods supported.

Another argument in favor or requiring CAs to accept problem reports via
email is that it provides the reporter with evidence of the submission via
their email client and server logs.

Arguments against this requirement include the burden placed on CAs who
must sort through the large quantities of SPAM received by any published
email address, concerns with email reliability, and the reporter's
inability to confirm that their email has been received by the CA.

According to CCADB [1], all but a handful of CAs already support problem
reporting via email.

I would appreciate everyone's input on this topic.

This is: https://github.com/mozilla/pkipolicy/issues/98

[1]
https://ccadb-public.secure.force.com/mozilla/ProblemReportingMechanismsReport
-------

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md

[Jeremy Rowley]

I believe the intent of the certificate problem reporting in the BRs is to encourage CAs to accept and respond to issues. Although the intent is not specifically stated, my reasoning is based on the fact the BRs requiring CAs to maintain a 24x7 ability to respond, a 24 hour ability to process certificate problems, and a public reporting mechanism. To support this objective, I think we should make the process as easy as possible for reporters, including mandating email. Finding the email addresses is a pain with little reward. Having to go through captchas to even get the email sent is just another obstacle in getting the CA a timely certificate problem report. Therefore, I'd adopt Ryan Hurst's proposal and require that the email be in a standardized format (no more hunting for email aliases) without any blockers to prevent the certificate problem report. Filtering through the mess of emails you get on those aliases is the CAs responsibility.

Jeremy

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Dimitris Zacharopoulos]

On 18/4/2018 12:04 πμ, Jeremy Rowley via dev-security-policy wrote:
> Having to go through captchas to even get the email sent is just another obstacle in getting the CA a timely certificate problem report

Nowadays, people deal with captchas all the time in various popular web
sites. I don't understand this argument. Is someone wants to file a
certificate problem report, they will take the extra "seconds" to pass
the "I am not a robot" test :)

Mail servers receive tons of SPAM everyday and an email address target
is a very easy target for popular CAs. We should also consider the
possibility of accidental "spam labeling" of a certificate problem
report via email.

I believe CAs should include the necessary information for receiving
Certificate Problem Reports in section 1.5.2 of their CP/CPS and this
should be required by the Mozilla Policy for consistently. The same
applies for the "high-priority" Certificate Problem Reports as mandated
in 4.10.2 of the BRs.


Dimitris.

[Ryan Sleevi]

On Wed, Apr 18, 2018 at 3:14 AM, Dimitris Zacharopoulos via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

> Mail servers receive tons of SPAM everyday and an email address target is
> a very easy target for popular CAs. We should also consider the possibility
> of accidental "spam labeling" of a certificate problem report via email.
>

I have seen this happen with CAs when submitting problem reports on behalf
of Google - so this definitely happens :) I've had to follow-up directly
with contacts at the CA to make sure "they got it" in time.

[Wayne Thayer]

On Wed, Apr 18, 2018 at 12:14 AM, Dimitris Zacharopoulos via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

> On 18/4/2018 12:04 πμ, Jeremy Rowley via dev-security-policy wrote:
>
>> Having to go through captchas to even get the email sent is just another
>> obstacle in getting the CA a timely certificate problem report
>>
>
> Nowadays, people deal with captchas all the time in various popular web
> sites. I don't understand this argument. Is someone wants to file a
> certificate problem report, they will take the extra "seconds" to pass the
> "I am not a robot" test :)
>

> The arguments for email are:
1 - it's easier. I have seen CAs use generic "support request" forms that
are difficult to decipher, especially when not in one's native language.
2 - It scales better. When someone is trying to report the same problem to
a number of CAs, one email is better than filling out a bunch of forms
3 - It automatically creates a record of the submission. Many forms provide
the user no confirmation unless they remember to take a timestamped screen
shot.

> Mail servers receive tons of SPAM everyday and an email address target is
> a very easy target for popular CAs. We should also consider the possibility
> of accidental "spam labeling" of a certificate problem report via email.
>
>

I believe CAs should include the necessary information for receiving
> Certificate Problem Reports in section 1.5.2 of their CP/CPS and this
> should be required by the Mozilla Policy for consistently. The same applies
> for the "high-priority" Certificate Problem Reports as mandated in 4.10.2
> of the BRs.
>

> I plan to introduce a CAB Forum ballot for the 1.5.2 disclosure
requirement. I disagree with the suggestion that Mozilla policy should
duplicate the BRs "for consistency", but since Mozilla policy has a broader
scope than the BRs (email certificates), I will plan to add this
requirement.

>
> Dimitris.

[Ryan Sleevi]

On Wed, Apr 18, 2018 at 2:50 PM, Wayne Thayer via dev-security-policy <

dev-secur...@lists.mozilla.org> wrote:

> On Wed, Apr 18, 2018 at 12:14 AM, Dimitris Zacharopoulos via
> dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> > On 18/4/2018 12:04 πμ, Jeremy Rowley via dev-security-policy wrote:
> >
> >> Having to go through captchas to even get the email sent is just another
> >> obstacle in getting the CA a timely certificate problem report
> >>
> >
> > Nowadays, people deal with captchas all the time in various popular web
> > sites. I don't understand this argument. Is someone wants to file a
> > certificate problem report, they will take the extra "seconds" to pass
> the
> > "I am not a robot" test :)
> >
> > The arguments for email are:
> 1 - it's easier. I have seen CAs use generic "support request" forms that
> are difficult to decipher, especially when not in one's native language.
> 2 - It scales better. When someone is trying to report the same problem to
> a number of CAs, one email is better than filling out a bunch of forms
>

While this optimizes for problem reporters, rather than receivers, I worry
that the impact it would have to problem receivers - both in cost and
effectiveness (particularly for spam) - will effectively disadvantage
problem reporters.

Being on the receiving end of several email aliases for security bugs, the
noise to signal is... overwhelming. Even Mozilla now requires that security
issues in Mozilla products be reported through Bugzilla, rather than email
- and my understanding is for similar reasons.

> 3 - It automatically creates a record of the submission. Many forms provide
> the user no confirmation unless they remember to take a timestamped screen
> shot.
>

While this is true, would an alternative solution be to require that
problem reports receive a distinct confirmation ID (e.g. in the way that
Mozilla assigns bug numbers to problems reported through Bugzilla?). As
mentioned in the CA/Browser Forum regarding voting, there's a number of
ways and reasons for which mail might be 'sent' by a client but not ever
actually delivered to the recipient mailbox - hence the suggestion that
email itself is not sufficient to constitute a vote, but that its
availability on the public mail archives being that proof - aka, a stable,
distinct identifier.

[Dimitris Zacharopoulos]

On 18/4/2018 9:50 μμ, Wayne Thayer via dev-security-policy wrote:
> On Wed, Apr 18, 2018 at 12:14 AM, Dimitris Zacharopoulos via
> dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
>> On 18/4/2018 12:04 πμ, Jeremy Rowley via dev-security-policy wrote:
>>
>>> Having to go through captchas to even get the email sent is just another
>>> obstacle in getting the CA a timely certificate problem report
>>>
>> Nowadays, people deal with captchas all the time in various popular web
>> sites. I don't understand this argument. Is someone wants to file a
>> certificate problem report, they will take the extra "seconds" to pass the
>> "I am not a robot" test :)
>>
>> The arguments for email are:

When I wrote "I don't understand this argument" it was meant for the
"having to go through captchas". Sorry, it wasn't very clear.

> 1 - it's easier. I have seen CAs use generic "support request" forms that
> are difficult to decipher, especially when not in one's native language.
> 2 - It scales better. When someone is trying to report the same problem to
> a number of CAs, one email is better than filling out a bunch of forms

> 3 - It automatically creates a record of the submission. Many forms provide
> the user no confirmation unless they remember to take a timestamped screen
> shot.
>

Despite the arguments for email, there are equally good arguments for
web form submission. IMHO, both should be allowed. A CA could start with
email but if the spam volume becomes out of control, the CA might switch
to a web form solution and all we need to do is define the minimum
"properties" of such a solution. In all cases, CAs should maintain
up-to-date information for Certificate Problem Report submission methods
in CCADB.

>> Mail servers receive tons of SPAM everyday and an email address target is
>> a very easy target for popular CAs. We should also consider the possibility
>> of accidental "spam labeling" of a certificate problem report via email.
>>
>>
> I believe CAs should include the necessary information for receiving
>> Certificate Problem Reports in section 1.5.2 of their CP/CPS and this
>> should be required by the Mozilla Policy for consistently. The same applies
>> for the "high-priority" Certificate Problem Reports as mandated in 4.10.2
>> of the BRs.
>>
>> I plan to introduce a CAB Forum ballot for the 1.5.2 disclosure
> requirement. I disagree with the suggestion that Mozilla policy should
> duplicate the BRs "for consistency", but since Mozilla policy has a broader
> scope than the BRs (email certificates), I will plan to add this
> requirement.

Currently the BRs don't mandate listing this particular information in
1.5.2, so there is no consistency among CAs. So far, CCADB has the best
collection of this information and this was initiated by Mozilla in the
April 2017 CA Communication.
Historically, Mozilla had policies that passed on to the BRs and once
they were in the BRs, they were removed from the Mozilla policy as
duplicates :). We would support a ballot that would require CP/CPS
sections 1.5.2 to describe the CA's specific Certificate Problem Report
methods.


Dimitris.

[Kristian Fiskerstrand]

On 04/18/2018 10:51 PM, Dimitris Zacharopoulos via dev-security-policy
wrote:

>> 1 - it's easier. I have seen CAs use generic "support request" forms that
>> are difficult to decipher, especially when not in one's native language.
>> 2 - It scales better. When someone is trying to report the same
>> problem to
>> a number of CAs, one email is better than filling out a bunch of forms
>> 3 - It automatically creates a record of the submission. Many forms
>> provide
>> the user no confirmation unless they remember to take a timestamped
>> screen
>> shot.
>>
>
> Despite the arguments for email, there are equally good arguments for
> web form submission. IMHO, both should be allowed. A CA could start with
> email but if the spam volume becomes out of control, the CA might switch
> to a web form solution and all we need to do is define the minimum
> "properties" of such a solution. In all cases, CAs should maintain
> up-to-date information for Certificate Problem Report submission methods
> in CCADB.

Although I much prefer email as a submission method myself, another
argument is actually security. Given that most users (sadly) still don't
use OpenPGP or S/MIME, a web form allows encrypted submissions.

--
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

[Wayne Thayer]

At this point we have a few choices:

1. Do nothing about requiring email as a problem reporting mechanism.
Instead, take on the related issues of disclosure of the reporting
mechanism and receipt confirmation in Mozilla policy, via the CAB Forum, or
both.
2. Go ahead with the proposal to require email, but allow CAs to require
some special, but standardized identifier be placed in the message that
they can filter on. For example, CAs could ignore messages sent to their
problem reporting address unless the subject contains the phrase "problem
report".
3. Develop some new problem reporting mechanism that solves the problems
with email and forms. For example, we could require CAs to accept problem
reports posted to this list, but build in some additional time in which to
"receive" the report by reading list messages. Or we could require CAs to
accept problem reports via Bugzilla. We already see problems being reported
via these mechanisms and require CAs to monitor both of them, just not on a
24x7 basis.

The first option ('do nothing') is currently in the lead, so I would
especially like to hear from anyone who wants to argue for a different
solution.

- Wayne

[Wayne Thayer]

This discussion has resulted in no agreed-upon changes to the Mozilla
policy. I will close the issue on GitHub [1], and I also plan to propose a
CAB Forum ballot that includes the requirement for CAs to disclose their
problem reporting mechanism in section 1.5.2 of their CPS.

- Wayne

[1] https://github.com/mozilla/pkipolicy/issues/98