[cabfpub] [EXTERNAL] Brazilian bank DNS heist

[Eric Mill]

On Fri, Apr 7, 2017 at 10:23 AM, Ryan Sleevi via Public <public at cabforum.org
> wrote:

> That's just a press summary of what Bruce linked.
>
> It sounds like folks don't understand Ivan's criticisms or the problems
> with HPKP. Since this list is primarily targetted towards CAs, I encourage
> you to reach out to Ivan (or if he still lurks) about how CAs could make
> HPKP more viable, if they're interested. I've already described how CAs are
> uniquely qualified to provide that assistance. It's the lack of that
> assistance that has created the significant risks. That's not something
> Gerv or Jody and I can solve - that's on CAs.
>
> This is no different than, for example, CAs needing to disclose what CAA
> domains they accept, as otherwise, CAA cannot be (effectively) used.
>

To try and sum up what I think Ryan is saying, CAs could use HPKP to
achieve the same effect as an "EV-Only" pin if CAs each publicly published
and maintained the hash of their public keys that correspond to EV-only
issuing CAs, for customers to rely on.

Then a customer who doesn't wish to pin to a small set of CAs or end entity
certs, out of fear of bricking themselves, could construct an "EV-only" set
of pins that encompassed all publicly trusted EV-issuing CAs. The technical
risks would be similar than a hypothetical "EV-only" pinning standard, and
require no further effort on the part of browsers.

The primary issue for server operators is that that server operators would
need to keep their pins up to date as the set of EV-only issuing CAs
change, but I would think that that rate of change might be manageable, and
even a fairly out-of-date set of pins would still leave ample breathing
room to migrate CAs if an issue occurs.

The primary issue for CAs is that you'd really want to coordinate to put
these in one place, and maintain an authoritative "EV-only" set of pins for
server operators to refer to. It wouldn't be reasonable to ask interested
server operators to hunt it all down and construct the pins themselves, and
wouldn't be effective -- people would make mistakes and then blame the CAs.

This is the sort of thing I'd think that CAs and groups invested in EV,
such as the CA Security Council, might promote. If the market is actually
interested in the concept of "EV-only" pinning, this would be a great way
to demonstrate it.

-- Eric


> On Fri, Apr 7, 2017 at 10:21 AM, Christian Heutger <ch at psw.net> wrote:
>
>> HPKP is vulnerable, look at https://www.heise.de/security/
>> artikel/Wachsende-Kritik-an-Public-Key-Pinning-fuer-HTTPS-3324703.html
>> (you may use Google Translator) from second headline
>>
>>
>>
>> *Von: *Public <public-bounces at cabforum.org> im Auftrag von Ryan Sleevi
>> via Public <public at cabforum.org>
>> *Antworten an: *CA/Browser Forum Public Discussion List <
>> public at cabforum.org>
>> *Datum: *Freitag, 7. April 2017 um 16:16
>> *An: *Bruce Morton <Bruce.Morton at entrustdatacard.com>
>> *Cc: *Ryan Sleevi <sleevi at google.com>, CA/Browser Forum Public
>> Discussion List <public at cabforum.org>
>> *Betreff: *Re: [cabfpub] [EXTERNAL] Brazilian bank DNS heist
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Apr 7, 2017 at 9:27 AM, Bruce Morton <
>> Bruce.Morton at entrustdatacard.com> wrote:
>>
>> Sorry I missed that, but isn’t pinning high risk? I don’t think that any
>> CA would recommend pinning as it is unsupportable; we can’t do anything
>> when it fails. I think Subscribers should review pinning before deploying,
>> https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-
>> key-pinning-dead.
>>
>>
>>
>> For what it's worth, many of the complaints in that blog relate to CAs
>> lack of disclosure related to their infrastructure - that's what creates
>> the risks. So if CAs were more technically savvy, and worked to help
>> understand their customers needs, it's very much viable.
>>
>>
>>
>> I think the value of EV is that those certificates are not issued to
>> attackers. So it would be great if a Subscriber could state that their site
>> only uses EV and that the browser respected that statement.
>>
>>
>>
>> And customers have that capability - if CAs, particularly their CA, is
>> technically capable and/or transparent. The browser manufacturers have
>> already give you that capability, if you chose to use it.
>>
>>
>>
>> I also think that this statement might be better to be put in the HSTS
>> header. HSTS is low risk, EV is highly available and stating EV-only would
>> be applicable to most CAs. This allows the Subscriber to move from one CA
>> to another without bricking their site by pinning to a root or intermediate.
>>
>>
>>
>> I disagree, and was pointing out how you can already accomplish this
>> without requiring new features that accomplish the same as existing
>> features =)
>>
>>
>>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>


-- 
konklone.com | @konklone <https://twitter.com/konklone>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170410/a59e15d4/attachment-0003.html>