Thanks Ryan.

>>  I don't believe this proposal - in its current form - will prove
>>  effective in the canonical cases: (1) CA failure like Diginotar; and
>>  (2) MitM attacks like Superfish. Are there other obvious cases I
>>  missed that this control will be effective?
>
> You're factually wrong in cases like (1), and woefully misguided in cases
> like (2) if you believe _any_ software, on a general purpose operating
> system with 1-layer security principals (such as Windows and OS X), can
> defend against a program with same-or-higher privileges.

You'll have to forgive my ignorance because the document states its
use to defend against some MitM attacks. The two canonical cases are
(1) Diginotar and (2) Superfish. We can defend against them with
pinning, so its not clear to me why browsers are having such trouble
with it.

Please humor me: what are the cases this security control defends
against? Again, please forgive my ignorance. The document does not
lists the cases it defends against, so I had to ask. That points to a
gap in the document that needs to be improved.

If HPKP can't handle (1) Diginotar and (2) Superfish, then it looks
like a placebo to me. Its does a disservice by providing a false sense
of security. But I'm probably wrong and I'd like to understand what
security benefits HPKP provides.

For completeness, I have not explored how HPKP interacts with self
signed certificates. If it only serves to bar them, then I'd say the
authors managed to get the CA/B Forum agenda furthered at the IETF. I
think they call that "confused deputy" in computer security circles.
But again, I could be wrong.

> That's like complaining a program with root access can interfere with your
> usermode application. Well, yes, that's exactly correct, that's how it's
> supposed to work.

Not exactly. These are two userland programs. One is not in a more
privileged position than the other.

> There is no sane world in which anything in the HPKP spec can or should
> deal with this.

Disagree. We use pinning to control that risk.

The pain point for browsers seems to be they want strong
authentication assurances while accommodating interception. That's a
self made problem.

> It's doubly true and hopefully self-evident that "raising
> the bar" is not at all an acceptable, or even reasonable, justification.
> Malicious actors have every reason to escalate to more nefarious means
> (whether for profit or interception), while legitimate actors get shut out
> or, equally, burrow further into internals and cause worse experiences for
> everyone.

Wow, I can't believe you're begging that argument.

If I apply that thinking, then there's no need for HPKP in the first
place. Or Secure Cookies, HTTP Only, HSTS, CSP, HTTPS (and friends)
for that matter.

> I understand that you disagree. But you're also wrong if you think HPKP
> can or should have dealt with this.

Again, disagree. We use pinning to control that risk.

Again, the pain point for browsers seems to be they want strong
authentication assurances while accommodating interception. That's a
self made problem.

*****

>>  IETF leadership: Carl Sagan once asked, who speaks for the Earth. Who
>>  here speaks for the users and sites? Does it *really* sound like a
>>  good idea to suppress evidence of validation failures and unauthorized
>>  overrides for a security control that's specifically designed to
>>  contend with the threats?
>
> This spec speaks for the users, by ensuring that local privacy rights
> trump remote server policy.

Reporting and logging needs to be fixed.

One report per origin does not facilitate tracking. By definition, you
need more than one report to "track".

If browsers were really interested in fixing tracking and addressing
anonymity, then "Do Not Track" would be default out of the box; Google
would honor "Do Not Track"; Google would not be subverting "Do Not
Track" with tracker-breaking tricks; and ETAGS would be addressed.

Or, pick your poison: if "Do Not Track" is not sent, then send the
report. If "Do Not Track" is sent, then don't send the report. You
guys have painted yourself into a corner with that one because you're
insecure out of the box and you want to be part of the cover up. Until
your cause is just, you're going to fall into simple traps like that.

And I might as well hit the obvious: the user gave up expectations of
anonymity with their first TCP SYN. If a user wants anonymity, then
they need to use a suitable technology like Tor.

*****

One of the things that's clear/evident is the browser architects are
having troubles because they want strong server authentication and
accommodate interception. They are competing goals and something has
to give (they may even be diametrically opposed).

I think browser architects and the security community need a Key Usage
of INTERCEPT to help differentiate the cases. It will help browsers
and other user agents differentiate the "good" bad guys from "bad" bad
guys. It will also help them determine when its OK to break a known
good pinset.

CAs surely won't issue INTERCEPT certificates and (I believe) most
folks won't declare INTERCEPT, so you've avoided the problem for a
majority of the use cases (over 90%?). That's a huge step forward in
helping browsers and other UAs differentiate the "good" bad guys from
"bad" bad guys.

The "good" bad guys will honor it and you'll know you're dealing with
a "good" bad guy. The "bad" bad guys will not honor it and you'll know
you're dealing with a "bad" bad guy. In this case of a "bad" bad guy,
UAs should refuse to break the pinset. And UAs won't fall victim to
the Diginotar and Superfish cases.

Organizations that install a CA to perform device management or
facilitate browsers and email programs can side step the whole
interception problem by not declaring them in the first place.
Browsers and users will not be put in the middle, and the problem will
be avoided. That's a huge step forward in helping UAs differentiate
the "good" bad guys from "bad" bad guys.

UAs won't fall victim to Diginotar and Superfish in its current
rendition because they lack the declaration. In the future, it will be
easily auditable by security software so the Superfishes cannot fly
under the radar. And if a CA is compromised and starts issuing
INTERCEPT certificates, then alarm bells will go off. The audits and
alarm bells will elicit so much negative press and publicity that
something will bend or break somewhere. That's Palmer's "shame as a
security control" and its a wonderful application of it because its
proactive (and not reactive).

Users like me who want nothing to do with interception can use a
different media (like switching to 3G/4G from Wifi) or will move the
INTERCEPT certificates to the Untrusted Store. I'd rather fail the
connection, but you've taken that choice away from me.

Now, if browser architects want to continue the surreptitious
interception and help in the cover up, then that's a different
problem. I suspect that's the agenda, and now is your opportunity to
prove folks like me wrong.

Jeff