[cabfpub] [EXTERNAL] Brazilian bank DNS heist

[Ryan Sleevi]

On Thu, Apr 13, 2017 at 10:47 AM, Rob Stradling <rob.stradling at comodo.com>
wrote:
>
> They _could_, for sure.
>
> But "they should"?  Citation needed.  What root program(s) require this
> today?


Microsoft's most recent policy update proposed adding this, but it was
pointed out that CAs are not presently doing that. I think that's a
reasonable statement for SHOULD, but not MUST, to borrow from RFC 2119.

After all, by separating out unique issuance, CAs enable their customers to
improve their security stance. I should hope the position you're advocating
is not that the only things worth doing are those which are required on CAs
- that'd be a rather cynical take on the state of CA security.


> OK, so there are at least 3 groups of intermediates that issue EV certs:
>   1. Issue EV certs, but also issue non-EV certs.
>   2. Issue only EV certs, but not trusted for EV on all EV-capable
> browsers.
>   3. Issue only EV certs, and trusted for EV on all EV-capable browsers.
>
> I agree that 'any site operator would need to know what constitutes as "EV
> only"', so yes, there would need to be an official list of "EV only" (group
> 3) intermediates/pins published somewhere, and maintained. (Publication and
> maintenance of such a list could be largely automated by adding a page to
> crt.sh or some other root program aggregator service).


I disagree, and of course, do not support that. Group 2 is wholly
sufficient for the security needs of users, and avoids introducing an
additional third party (browsers) into mediating that relationship. I would
be happy to point out a variety of CAs who have had difficulty in having
their roots or intermediates EV recognized, due to incomplete audits or
documentation. Were such an "EV only" policy implemented as you've
proposed, those CAs would find themselves unable to provide their services
to customers. I'm sure you can appreciate why CAs should find that
undesirable.

A cynical take would be to suggest that by defining it as Group 3, it may
be an attempt by CAs to "increase" the compatibility risk of removing EV
for a particular CA, thereby trying to capture more of the market. Whether
or not that is the intent, that would certainly be a result, and as such,
would be unquestionably unacceptable from the browser side, and thus
unlikely to ever be supported. By going through Group 2, those issues are
ameliorated regardless of whether or not the browser supports or recognizes
the CA's EV status, and Group 2 is fully accomodated today by browsers via
HPKP.


> Checking != Updating.
>
> Both your HPKP-based approach and my HSTS-based approach would require the
> site operator to regularly check that the EV intermediate they currently
> use is still on the group 3 list.
>
> However, your HPKP-based approach would also require the site operator to
> add/remove a pin every time a different EV intermediate is added/removed
> from the group 3 list.


Again, my proposal has nothing to do with Group 3 in order for site
operators to recognize the security benefits nominally afforded by the
enhanced vetting claimed by EV. It only requires that issuing CAs make a
distinction between Group 1 and Group 2, and to allow subscribers to choose
to pin to Group 2. It leaves the trust relationship solely between the
customer and the set of issuing CAs, and if a customer cannot trust a CA to
follow its own CP/CPS, well then, what good is anything?


> Not at all.  I was merely looking at the current landscape and attempting
> to determine the path of least resistance towards a maintainable solution.


Right, the HPKP solution can be implemented tomorrow, with the only change
being on CAs that don't already distinguish from EV capable intermediates
and non-EV capable intermediates. That is, quite literally, the path of
least resistance :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170413/c7303eaa/attachment-0003.html>