[cabfpub] [EXTERNAL] Brazilian bank DNS heist

[Rob Stradling]

On 13/04/17 15:57, Ryan Sleevi wrote:
> On Thu, Apr 13, 2017 at 10:47 AM, Rob Stradling 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.

You got a link for that?

On https://aka.ms/rootcert, the closest thing I see is...
"New intermediate CA certificates under root certificates submitted for 
distribution by the Program must separate Server Authentication, S/MIME, 
Code Signing and Time Stamping uses. This means that a single 
intermediate issuing CA must not be used to issue both server 
authentication, S/MIME, and code signing certificates. A separate 
intermediate must be used for each use case."
...which doesn't mention EV at all.

> 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,

Ah, you're right.  My mistake.

Group 2 is sufficient for the HPKP-based approach.  The "EV only" 
intermediates do need to only issue EV certs, but those intermediates 
don't need to be trusted-for-EV by all browsers.  (They do of course 
need to be trusted-for-serverAuth by all browsers though).

BTW, did your "not support that" comment also apply to the idea of 
adding a page to crt.sh (or some other root program aggregator service) 
that would automatically maintain the list of (group 2!) "EV only" 
intermediates?

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

I like a good conspiracy theory as much as the next guy, but I'm afraid 
in this case it was just insufficient coffee.  :-)

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

Yeah, you've convinced me now.  Thanks for helping me to get my head 
around this.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online