[cabfpub] Ballot 218 version 2: Remove validation methods #1 and #5

[Ryan Sleevi]

On Mon, Jan 29, 2018 at 3:16 PM, Mike Reilly (WDG) <
Mike.Reilly at microsoft.com> wrote:

> Ryan, I definitely agree there is a security risk with 3.2.2.4.1 and any
> other validation method entirely dependent on a “trust us” model.  I did
> see the specifics Jeremy shared about the problems with method 1 in an
> earlier thread.  You mention in your first reply that “*To date, Entrust
> has not provided any of the requested details about its use of 3.2.2.4.1,
> the prevalence, and the potential impact*” and then later state “*the
> security risk posed by the arbitrariness allowed, which Entrust has
> specifically demonstrated their systems are vulnerable to, presents an
> unacceptably large risk to our users.”  *
>
>
>
> Did I miss a post by Entrust where they specifically provided this
> security risk detail?  *Bruce* do you have this info?
>

Entrust has not themselves identified the security risk, although it has
been pointed out by others.

To recap the conversation to date:
- Jeremy Rowley of DigiCert points out the inherent security risks, as
written - https://cabforum.org/pipermail/public/2017-December/012660.html
  - And further expanded on this in
https://cabforum.org/pipermail/public/2018-January/012683.html
- Bruce Morton of Entrust details how Entrust performs this validation -
https://cabforum.org/pipermail/public/2018-January/012691.html
  - Potential problem shared by Jeremy Rowley -
https://cabforum.org/pipermail/public/2018-January/012694.html
  - Potential problem shared by Ryan Sleevi -
https://cabforum.org/pipermail/public/2018-January/012697.html
  - Potential problem shared by Jonathan Rudenberg -
https://cabforum.org/pipermail/public/2018-January/012816.html /
https://cabforum.org/pipermail/public/2018-January/012835.html
  - Potential problem shared by Geoff Keating -
https://cabforum.org/pipermail/public/2018-January/012836.html
  - Potential problem shared by Ryan Sleevi -
https://cabforum.org/pipermail/public/2018-January/012834.html

During that discussion, the case of how to handle CAs that are registrars
was raised - and addressed (e.g.
https://cabforum.org/pipermail/public/2018-January/012729.html ) - the same
as situations for handling TLDs that do not operate WHOIS services (
https://cabforum.org/pipermail/public/2018-January/012712.html )

Further, during the discussion of Entrust's application of 3.2.2.4.1, it
was clear that part of that process involved a contact with the
organization (per 3.2.5). However, that contact is using unvetted
information, since it simply uses a Reliable Method of Communication.
Gervase Markham proposed that the concerns could be addressed by contacting
the domain holder based on the domain information -
https://cabforum.org/pipermail/public/2018-January/012828.html - which is
just an application of 3.2.2.4.2/.3 -
https://cabforum.org/pipermail/public/2018-January/012833.html

I believe we can comfortably state that the amount of effort, and level of
communication, remains the same in the removal of 3.2.2.4.1 (as proposed to
218, which the addition of .12 and clarifications). So CAs that report it
as significant work are questionable, because it implies that they're doing
less work than those existing methods - which should understandably be
concerning, since 3.2.5 requires at least one customer engagement.

If we want to measure impact to the existing ecosystem, we'd need to
measure how many existing certificates are being reused with that
less-than-reliable information, which indicates an upper-bound of potential
revalidations - although given that these may be reusing information for a
domain (e.g. issuing multiple subdomains), it's likely that the actual
impact will be several orders of magnitude less. We can then measure this
against the total issuance volume within the ecosystem.

To date, information about that has not been shared - although most
recently requested in
https://cabforum.org/pipermail/public/2018-January/012834.html - and it's
very likely that there's an explanation for why that is, given that this
reason was offered previously by Entrust -
https://cabforum.org/pipermail/public/2017-May/010850.html - which is that
they only maintain these records in vetting files, rather than being
accessible or queryable information. It's unclear whether, in light of 190,
this has changed, but since it only requires that the CA record this
information 'somehow', rather than the proposed programattic method I
offered in May 2017 -
https://cabforum.org/pipermail/public/2017-May/010848.html - it's not
unreasonable to believe so, nor a violation of the BRs today to do so.

I hope this demonstrates the core facts:
- The method, as specifically documented by Entrust, does not provide
sufficient assurance, nor are they the only CA to have done this (c.f.
Symantec)
- The large scale risks (for ccTLDs and CAs-as-Registrars) are already
mitigated in Ballot 218
- No data has been shared, by any CA, that provides any actionable
information regarding their use of 3.2.2.4.1 and the potential impact. We
know that some CAs employ this method, we know that it will imply some
degree of revalidation, but no objective or actionable discussion about the
impact or data to support further delays has been shared.

I'm sensitive to the notion that changes in the BRs may impact those who
don't participate in the discussions, but I am uncomfortable allowing the
spectre of 'what if' to haunt us. This is further emphasized by the fact
that the information about what CAs use what methods should already be
available within their CP/CPS, as per both the BRs and various Root
Programs. So if someone wanted to argue about the potential impact, using
objective data, that data is readily available for them to collect and
present. The abstract hypothetical, however, is uncompelling.


>
> It sounds like all of us agree this risk needs to be mitigated and that
> some CAs are more capable than others to react to a change in validation
> method used.  I’m trying to get a feel for how much of our ecosystem
> (either # CAs, % of customer base or % of certs) relies on method 1 and
> what impact or disruption is caused to customers (both individual and
> enterprise) if a significant part of the CA community can’t respond quickly
> and efficiently to the change.  This may support a more deliberate
> implementation for the good of the entire ecosystem vs. just a few CAs or
> one Browser.
>
>
>
> Given Tim sent out Ballot 218 version 2 for discussion with an
> implementation date of August 2018 it sounds like Google would vote “no” if
> it went to vote.  I suppose how each CA votes would be illustrative of how
> much of the ecosystem is ready for an August implementation.
>

No, we'd vote Yes - for the Baseline Requirements, August is certainly a
low-end of a date. Later than August would be a No. But I don't think a
"Yes" vote is indicative of support for August being the latest valid date
- merely, the latest acceptable date for the BRs to reflect that.


>
>
> I’d really like to see the f2f meetings used to discuss these type of
> ballots and given #43 is a month away the timing seems appropriate.
> Discussion could continue for another month via email and teleconference
> and perhaps a better view of the business impact to customers could be
> assessed against the security risk of a graceful implementation.
>

While I'm certainly appreciative of the Forum to discuss these things, I
think with respect to Bruce's specific request that Root Programs hold off
taking steps to protect their users until the Forum has consensus is not
reflective of the product or security needs, and thus untenable. I think it
also reflects poorly on the Forum if we cannot come to consensus on
security-critical changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180129/9d553999/attachment-0003.html>