Subject: [websec] HPKP: The strict directive and TLS proxies

From: Yoav Nir <[email-masked]>
Date: Sun, 17 Nov 2013 07:53:18 +0000

Hi, all

I know this is late days and all, but something on the httpbis list got me to thinking about this.

Section 2.1.4 defines the "strict" directive. When present, it means that "the UA ... should apply to the Pinned Host the Pinning Policy expressed in the PKP header ... ignoring local client policy."

While the text does not say what this local policy might be, the reason for having this was the policy to allow locally-issued certificates to be used for pretty much anything. This policy accommodates TLS proxies. So if a security-minded bank would like to avoid interception even at the cost of being inaccessible from many places of business, they can use the "strict" directive. 

Now consider two devices. One is a mobile platform, could be a phone or a laptop, that the user carries around from home to work. The other is a desktop computer, that is always at work. The laptop will at some point be used at home to access the bank. The PKP gets noted, and from that point on, the user will not be able to access the bank from work. 

The desktop computer cannot note the PKP, and will always be able to connect to the bank. Section 2.5 says this:
   o  The UA MUST note the Pins if and only if the TLS connection was
      authenticated with a certificate chain containing at least one of
      the SPKI structures indicated by at least one of the given SPKI
      Fingerprints.

This rule is a safety rule, to avoid being injected with bogus PKPs, mostly through misconfiguration of the server. There are other requirements (that TLS be error-free) that make sure it is not done by an attacker (at least, not a non-trusted attacker). 

I'm wondering if we should remove this requirement from section 2.5 when the "strict" directive is present. IOW, should we allow noting of PKPs with the "strict" directive as long as the TLS connection is valid. I can see how this would make it easy for a TLS proxy to brick the browser, but I'm wondering what others think of the trade-off.

Yoav

---

From: Tom Ritter <[email-masked]>
Date: Mon, 18 Nov 2013 11:51:09 -0500

Hm.  Interesting predicament.  Two thoughts:

If the goal is to allow clients to note and obey the 'strict' directive
even in the face of a SSL Interception proxy... what you propose won't
work. The proxies will be built to just remove the strict directive, or
the header all together.

If the organization running the proxy wanted to block access to the site
in question, they would do so. If they want to monitor ongoing access,
they will strip the directive/header so the clients continue to connect.
If they are ambivalent - 'access it or not, we don't care, but must
monitor you if you do' - the stripping feature may or may not be enabled.

What you propose would only help in the latter case, it will not
actually provide more security if the website considers the proxy to be
an adversary. And if they add the strict header, I would imagine that
the website does consider them to be an adversary, or at least that they
do not wish the connection to succeed..

So I don't think what you propose is worthwhile, specifically because it
does add risk via sites bricking themselves, while not improving
security considerably.

As far as the laptop moving between home and work... I get the
impression this situation may be regarded as a 'failure' of the
protocol. That is, we have unintentionally broke something.  I disagree.
I think the situation has worked as desired.

Because if we replace the players with a rogue government performing TLS
MitM, with the specific goal of isolating clients from receiving
up-to-date security policies... we would declare this same situation a
success.

I don't see a way to reconcile the two situations, as they behave almost
exactly the same.

TLS Proxies add a third player into what was previously a (primarily)
two-party protocol*. I think the strict directive preserves the
reasonable property that any one of the three parties can choose not to
participate based on the settings of the protocol.
 - The TLS proxy can block access or choose not to intercept
 - The user can not visit the site
 - The site can declare "I don't want anyone else seeing the data I
consider to be for the user's eyes only"

I expect that Firefox and Google may even continue to preload entries in
their browsers that apply the 'strict' directive specifically to provide
websites the power to assert their right to a MitM-free connection. I
know several websites who would like to exercise that right.

-tom

* Yes yes, CAs make 3, but that's PKIX, not TLS.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 19 Nov 2013 23:36:55 +0000

> do not wish the connection to succeed..

I agree that it does not help security, but it increases the chances of the server policy being enforced. This is not far-fetched. Most TLS proxies are next-generation firewalls or caching proxies. They won't remove the strict directive.  Of course, snooping proxies will act differently.

> I think the situation has worked as desired.

It's the other way around. The desktop that remains at the office and keeps ignoring the strict pins is the failure.

> consider to be for the user's eyes only"

So the benevolent TLS proxy should note the "strict" directive and block the connection by itself? It makes sense, but that would require an upgrade of the TLS proxies. Changing client behavior would work with the proxies that are deployed now.

> know several websites who would like to exercise that right.

What? And have their sites not work in all the places that have newer firewalls?  I doubt it.

Anyway, I can see how this would allow a buggy proxy to brick the users, so I now agree that this is not worthwhile.

Yoav

---

From: Tom Ritter <[email-masked]>
Date: Tue, 19 Nov 2013 18:40:56 -0800

> It's the other way around. The desktop that remains at the office and keeps ignoring the strict pins is the failure.

Ah, I agree with that, also.  I was anticipating an argument that the
laptop had been 'broken' by the migrating.

> So the benevolent TLS proxy should note the "strict" directive and block the connection by itself? It makes sense, but that would require an upgrade of the TLS proxies. Changing client behavior wou…

Not necessarily.  Really I meant that I, as the maintainer of the SSL
MITM device at FooCorp could decide "Employees aren't allowed to use
personal WebMail at work" and then enforce that with blocking.

Auto-Blocking based off 'strict' would absolutely require upgrades, but
that wasn't my meaning.

> What? And have their sites not work in all the places that have newer firewalls?  I doubt it.

/shrug

I can hope.  :)

-tom

---

From: "Ryan Sleevi" <[email-masked]>
Date: Wed, 20 Nov 2013 12:23:25 -0800

On Tue, November 19, 2013 3:36 pm, Yoav Nir wrote:
>  I agree that it does not help security, but it increases the chances of
>  the server policy being enforced. This is not far-fetched. Most TLS
>  proxies are next-generation firewalls or caching proxies. They won't
>  remove the strict directive.  Of course, snooping proxies will act
>  differently.
>
>  It's the other way around. The desktop that remains at the office and
>  keeps ignoring the strict pins is the failure.
>
>  So the benevolent TLS proxy should note the "strict" directive and block
>  the connection by itself? It makes sense, but that would require an
>  upgrade of the TLS proxies. Changing client behavior would work with the
>  proxies that are deployed now.
>
>  Anyway, I can see how this would allow a buggy proxy to brick the users,
>  so I now agree that this is not worthwhile.
>
>  Yoav
>
>  _______________________________________________
>  websec mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/websec
>

Apologies that this discussion has happened due to the editors not having
refreshed the draft.

As I recall (perhaps incorrectly), our takeaway from IETF 86 was the
removal of the 'strict' directive, since the notion of having a remote
server provide a directive to override local policy is just escalating a
policy arms race.

One of the key discussions was had was regarding pinning and how, in
current implementations (eg: Chrome), one can only pin to chains that
terminate in a 'well-known root'. The 'strict' directive (or its absence)
was an attempt to provide some indication that the site accepts being
pinned to an internal trust anchor.

I recall (and again, perhaps incorrectly), that it was either Eric
Rescorla or Jeff Hodges that suggested an implementation change might
better accomodate this:
1) If noting pins, and it chains to a well-known trust anchor, local
policy (read: potentially MITM enterprise devices) may be able to override
2) If noting pins, and it does not chain to a well-known trust anchor,
effectively note the pins with no override capability (eg: the pins
exactly as specified)

The goal of this was less about enabling MITM proxies (although they're an
unfortunate reality and, to at least some, a perceived necessity), and
instead finding a way to balance pinning for both "public" sites as well
as "internal" sites.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 20 Nov 2013 23:36:09 +0200

> server provide a directive to override local policy is just escalating a
That was issue #53. It was closed, and there was no consensus to remove 
'strict'. The only things missing from the draft is the closing of #57-#60.
> instead finding a way to balance pinning for both "public" sites as well
I'm not sure of the value of pinning internal sites. But regardless, I 
think the text with the changes agreed upon for the few open issues 
reflects the consensus of the group or what's left of it (the group, not 
the consensus).

I think it's time to push this out.

Yoav

---

From: Chris Palmer <[email-masked]>
Date: Mon, 25 Nov 2013 19:41:02 -0800

> 'strict'. The only things missing from the draft is the closing of #57-#60.

Issue 53 (http://tools.ietf.org/wg/websec/trac/ticket/53) was not
quite about the policy arms race.

The policy arms race between public web site www.example.com and a
given client's filtering TLS proxy is over: if the client legitimately
trusts the TLS proxy (e.g. the TLS proxy's trust anchor is installed
in the client's trust anchor store), then www.example.com cannot
enforce its policy on the client; in effect, the proxy is the true
client. On the other hand, if the client does *not* trust the TLS
proxy, then the proxy will be "caught" either by pinning or by the
usual "The server presented a certificate your operating system does
not trust" warning screen. So I don't think it is possible or sane to
promise to site operators that they can deny MITM powers to MITMs that
the client trusts.

As I (think we) intended it, strict was to mean "bypass the local
policy of not applying pinning to chains that chain to local trust
anchors" — i.e. as a way of allowing sites that install their own
trust anchors on machines to also pin the keys of the servers that the
local trust anchor signs. This would be for enterprises that want to
have their own PKI and also strictly enforce it (to ensure that, e.g.,
internal.example.com never chains to a public anchor). The utility of
this is debatable (but, I would argue, more than 0... potentially).

There is a new draft -09 in our Git repo at
https://code.google.com/p/key-pinning-draft/source/browse/draft-ietf-websec-key-pinning.xml.
Any thoughts before I actually put it in the IETF tracker as the real
-09?

---

From: Yoav Nir <[email-masked]>
Date: Tue, 26 Nov 2013 10:14:06 +0200

> Any thoughts before I actually put it in the IETF tracker as the real
Thanks, Chris.

To summarize, although there has been much discussion since version -06, 
most of it did not result in massive changes to the document, so IMO we 
don't need another WGLC. If anyone feels differently, please let me know 
by the end of this week.

Pasted below is the privacy considerations section, which is new to this 
version.

There is one thing that I think needs fixing before submitting: the IANA 
considerations section. It says that this document has no actions for 
IANA. This is wrong. IANA keeps the registry for HTTP (among other 
things) headers:
http://www.iana.org/assignments/message-headers/message-headers.xhtml

So it should be something like

6. IANA Considerations

IANA is requested to register the header described in this document in 
the "Message Headers" registry, with the following parameters:
    o  Header Field Name should be "Public-Key-Pins"
    o  Protocol should be "http"
    o  Status should be "standard"
    o  Reference should be this document

Thanks,

Yoav

Here's a paste of the new section 5:

5.  Privacy Considerations

    Conforming implementations (as well as implementations conforming to
    [RFC6797]) must store state about which domains have set policies,
    hence which domains the UA has contacted.  A forensic attacker might
    find this information useful, even if the user has cleared other
    parts of the UA's state.

    More importantly, Hosts can use HSTS or HPKP as a "super-cookie", by
    setting distinct policies for a number of subdomains.  For example,
    assume example.com wishes to track distinct UAs without explicitly
    setting a cookie, or if a previously-set cookie is deleted from the
    UA's cookie store.  Here are two attack scenarios.

    1.  example.com can use report-uri and the ability to pin arbitrary
        identifiers to distinguish UAs.

    2.

        1.  example.com sets a Valid Pinning Header in its response to
            requests.  The header asserts the includeSubDomains
            directive, and specifies a report-uri directive as well.
            Pages served by the host also include references to
            subresource https://bad.example.com/foo.png.

        2.  The Valid Pinning Header includes a "pin" that is not really
            the hash of an SPKI, but is instead an arbitrary
            distinguishing string sent only in response to a particular
            request.  For each request, the Host creates a new, distinct
            distinguishing string and sets it as if it were a pin.

        3.  The certificate chain served by bad.example.com does not pass
            Pin Validation given the pin set the Host asserted in (1).
            The HPKP-conforming UA attempts to report the Pin Validation
            failure to the specified report-uri, including the
            certificate chain it observed and the SPKI hashes it expected
            to see.  Among the SPKI hashes is the distinguishing string
            in step (2).

    3.  example.com can use SNI and subdomains to distinguish UAs.

    4.

        1.  example.com sets a Valid Pinning Header in its response to
            requests.  The header asserts the includeSubDomains
            directive.

        2.  On a subsequent page view, the Host responds with a page
            including the subresource https://0.fingerprint.example.com/
            foo.png, and the server responds using a certificate chain
            that does not pass Pin Validation for the pin-set defined in
            the Valid Pinning Header in step (1).  The HPKP-conforming UA
            will close the connection, never completing the request to
            0.fingerprint.example.com.  The Host may thus note that this
            particular UA had noted the (good) pins for that subdomain.

        3.  example.com can distinguish 2^N UAs by serving Valid Pinning
            Headers from an arbitrary number N distinct subdomains,
            giving some UAs Valid Pinning Headers for some, but not all
            subdomains (causing subsequent requests for
            n.fingerprint.example.com to fail), and giving some UAs no
            Valid Pinning Header for other subdomains (causing subsequent
            requests for m.fingerprint.example.com to succeed).

---

From: Chris Palmer <[email-masked]>
Date: Tue, 26 Nov 2013 15:38:43 -0800

On Tue, Nov 26, 2013 at 12:14 AM, Yoav Nir <[email-masked]> wrote:

> considerations section. It says that this document has no actions for IANA.
> This is wrong. IANA keeps the registry for HTTP (among other things)
> headers:
> IANA is requested to register the header described in this document in the
> "Message Headers" registry, with the following parameters:

OK, I set it to this. Thanks!

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 29 Nov 2013 12:24:58 -0800

On Tue, Nov 26, 2013 at 12:14 AM, Yoav Nir <[email-masked]> wrote:
> don't need another WGLC.

 * Weren't we going to discuss the relationship of preloaded to
dynamic pins?  See email [1].

 * The rationale in thread [2] for "strict" seems different from the
rationale in previous list discussions [3].  Ryan now argues that
"strict" is not needed.  I think that's worth considering.

 * I had feedback on an earlier draft which is still relevant [4], see below.

[1] http://www.ietf.org/mail-archive/web/websec/current/msg01938.html
[2] http://www.ietf.org/mail-archive/web/websec/current/msg01942.html
[3] http://www.ietf.org/mail-archive/web/websec/current/msg01484.html
[4] http://www.ietf.org/mail-archive/web/websec/current/msg01692.html

FEEDBACK ON DRAFT-07, STILL RELEVANT
====

 * Interaction with cookies needs discussion.  Cookie scoping rules
pose a serious problem for pinning, e.g. a pin at "example.com" could
be undermined by a MITM inventing a "badguy.example.com" and using it
to steal or force cookies.

 * Why is there a "Public-Key-Pins-Report-Only" header instead of a
"report-only" directive?  Most of the document is written as if there
was a single "PKP header field", so a directive would make more sense.

 * In draft-05, client processing was changed from noting a single
"expiry" value to noting two values: "Effective Pin Date" and
"max-age".  The previous approach was simpler, stored less data, and
was more aligned with HSTS.

 * Section 2.3.1 fails to update the Effective Date of a noted pin
when it is noted again.

 * Section 2.6 mandates "When a UA connects to a Pinned Host, if the
TLS connection has errors, the UA MUST terminate the connection
without allowing the user to proceed".  HSTS allows the server to
specify this, so it seems unnecessary and inflexible to mandate it
here.  It's also unclear whether a "report-only" pin counts as a
"Pinned Host".

 * UA processing rules are confusingly spread across the document.
For example, 2.3.1 and 2.5 describe the same process so should be
combined.

 * Section 2.5 - Does a failed validation of a "report-only" pin count
as an "error" that will inhibit noting of new pins in the connection?

 * Specified UA behavior with multiple header fields is contradictory:
 - 2.1.3: "If a Host sets both the Public-Key-Pins header and the Public-Key-
    Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, and
    MUST note only the pins and directives given in the Public-Key-Pins-
    Report-Only header."
 - 2.3.1: "If a UA receives more than one PKP header field in an HTTP
    response message over secure transport, then the UA MUST
    process only the first such header field."

 * Section 3 - Should the failure report contain the certificates sent
by the server, as well as the validated chain?  Could help debugging
and attack analysis.

 * Why is SHA1 supported?  If the reason is size, why not remove it
but allow the server to pin to a truncated hash (e.g. pin to the first
16 or 20 bytes of SHA256)

 * Should there be a list of "excluded" keys that must not appear in
the "validated certificate chain"?  Chrome's preloaded pinning
supports this, apparently to exclude 3rd-party subCAs that might have
been issued under a pinned CA.

 * Would it be better to use the term "pin" for the entire record
associating (hostname, HPKP data), instead of calling each individual
hash a "pin"?  The hostname is "pinned" to the 1-of-n key set as a
whole, not each key individually.

 * Should the header name be changed once this draft stabilizes, to
ensure no bad interactions with UAs that implemented earlier drafts?

Minor:
 * "Pinning Policy" and "Pinning Metadata" are synonyms?
 * 2.3.1 ... "or," ... "Otherwise" is confusing
 * 2.3.2 - are clients expected to store directives they don't understand?
 * 2.6 - is pin validation performed on resumed TLS connections?
 * 3 - can UAs provide additional JSON fields inside the report?
 * The term "validated certificate chain" is not defined
 * An IANA registry is needed for directives
 * The acknowledgement for "pin break codes" is ancient/irrelevant

Trevor

---

From: Tom Ritter <[email-masked]>
Date: Fri, 29 Nov 2013 17:15:57 -0500

> was a single "PKP header field", so a directive would make more sense.

If it becomes a directive, we should be sure that we can still apply two
headers, one more loose in enforcing mode, one stricter in report only
mode.

-tom

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 29 Nov 2013 14:39:10 -0800

On Fri, Nov 29, 2013 at 2:15 PM, Tom Ritter <[email-masked]> wrote:
> headers, one more loose in enforcing mode, one stricter in report only mode.

Would you expect both headers to be noted?

The current spec doesn't support that.  It specifies 2 different (and
incompatible) ways of handling this case:

Trevor

---

From: Tom Ritter <[email-masked]>
Date: Fri, 29 Nov 2013 17:50:43 -0500

>     process only the first such header field."

Oh yea. Heh.  Why is that?  CSP supports an enforcing header and a
reporting header, and both of them are applied simultaneously. I would
expect the same from HPKP.

-tom

---

From: "Ryan Sleevi" <[email-masked]>
Date: Fri, 29 Nov 2013 15:57:01 -0800

>  expect the same from HPKP.

Spec bug. I'll see about getting that fixed.

The PKP + PKP-Report-Only mode are meant to be parallel to their concepts
from CSP. That is, the PKP-Report-Only directive is not enforced, but if a
PKP header is present, or PKPs are noted from previous, they are still
enforced.

---

From: "Ryan Sleevi" <[email-masked]>
Date: Fri, 29 Nov 2013 16:14:57 -0800

>  to steal or force cookies.

I still disagree that the *pin* can be undermined.

>  was a single "PKP header field", so a directive would make more sense.

Similar to CSP. A PKP might specify a looser-policy, while PKP-Report-Only
is used to test a more restrictive policy for deployment.

>  here.  It's also unclear whether a "report-only" pin counts as a

This is a feature, not a bug.

PKP is useful without mandating HSTS. However, the security advantages of
PKP can be undermined, much the way HSTS's can, if the UA allows users to
bypass.

It would be unnecessary and inflexible to mandate HSTS in order to obtain
security with PKP.

>  as an "error" that will inhibit noting of new pins in the connection?

No. Happy to clarify that.

>      process only the first such header field."

Not contradictory, but ambiguous. The presence of > 1 PKP or > 1 PKP-R-O
cause the first (PKP || PKP-R-O) field to be processed, and the rest
ignored. However, if both a PKP and PKP-R-O field are present, they are
both processed (independently).

The ambiguity is the term "PKP header field", which may be alternatively
written "more than one PKP header field or more than one PKP-R-O header
field". Does that satisfy your concern?

>  16 or 20 bytes of SHA256)

I won't attempt to assume any argument for you, but it sounds like you
oppose SHA-1. Perhaps you could state that, and your reasons why.

>  been issued under a pinned CA.

This was a temporary experiment that is no longer in use.

If such a feature is desirable, it seems like something that could be
addressed with additional directives in a later spec.

>  ensure no bad interactions with UAs that implemented earlier drafts?

This seems premature at best, but more likely an unwarranted and
unnecessary change.

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 29 Nov 2013 20:44:28 -0800

> I still disagree that the *pin* can be undermined.

Semantics aside, there should be Security Considerations about cookies.

> is used to test a more restrictive policy for deployment.

So the UA is going to maintain 2 stores of pins ("PKP" and "PKP-R-O"),
and process the "PKP" and "PKP-R-O" headers only against the
appropriate store?

That means asserting PKP:<new-pin> isn't sufficient to overwrite
existing pins.  You'd also have to assert PKP-R-O:max-age=0.

Seems OK, but none of this is in the draft.

> PKP can be undermined, much the way HSTS's can, if the UA allows users to

I think it's a mistake to mandate UI here.  "Users clicking through
legitimate security errors" is one risk.  "Users being denied access
to legitimate sites due to pinning failures" is another.

It's hard to know how to balance these.  We should allow UAs latitude.
 I suggest changing the text from MUST to SHOULD, at minimum.

> No. Happy to clarify that.

Should failed validation of a "report-only" pin inhibit noting of new
"report-only" pins?

> field". Does that satisfy your concern?

The draft is generally written as if there was a only single "header"
and a single stored "entry" for any site, so these sorts of changes
will probably need to be made elsewhere.

> oppose SHA-1. Perhaps you could state that, and your reasons why.

It's weaker than SHA-256.  I don't see a reason to bother with it.

It seems better to steer everyone towards one hash algorithm, to make
comparing pins easier.

> addressed with additional directives in a later spec.

OK.

> This seems premature at best, but more likely an unwarranted and

Chromium has had evolving, partial support for HPKP for some time.
Have these partial versions been shipping?

Are they likely to be "in the wild", with odd behavior that
HPKP-asserting sites might trigger?

Trevor

---

From: "Ryan Sleevi" <[email-masked]>
Date: Fri, 29 Nov 2013 23:47:01 -0800

>  Seems OK, but none of this is in the draft.

An artifact of when a PKP header was required (eg: implicit Max-Age). This
is because Report-Only doesn't/wouldn't need to be stored, because it is a
report-only mechanism. You simply evaluate the R-O on the current
connection (if a directive is present) and ping back.

As noted during Orlando, this is not a security mechanism, nor intended to
be one. It's a reporting/deployment testing mechanism. In that sense, R-O
still doesn't need to be stored, it could simply be "If present, evaluate
the connection against these [potential] pins". If absent, no R-O implied.

With the implementer hat on, I can go either way, but with a preference
towards the following: To me, R-O makes most sense when treated like CSP -
if present, report, otherwise, nothing. This is consistent with an
implicit Max-Age: 0, because no storage is required or performed.

> >>  was more aligned with HSTS.

Yet was very much intended to address the same concerns you raised
regarding the intersection between 'preloaded' and 'dyamic' pins, and the
WG seemed to support.

Do you have a proposal on how to reconcile these two items? Otherwise, it
seems like an issue that's impossible to address - on the one hand, an
objection to the ways that preloaded and dynamic may intersect, yet on the
other, an objection to attempts to attempts to clarify the ways that they
do.

>   I suggest changing the text from MUST to SHOULD, at minimum.

Thanks for your feedback. I'd like to hear from others in the WG if that
view is shared. To this point, we haven't heard any concerns about the
MUST, and the security properties are seemingly well understood.

Certainly, no UA vendor has asked or proposed such latitude. But then
again, we're all individuals here. I do fail to understand your
distinction between "legitimate security errors" and "pinning failures". I
would certainly count the latter amongst the former, and so I fail to see
how the risks differ, beyond being a superset/subset.

>  Should failed validation of a "report-only" pin inhibit noting of new

See above re: "noting" for R-O.

>  will probably need to be made elsewhere.

Single header, yes, updates needed.
Single stored entry, however, is hopefully addressed above.

>  It seems better to steer everyone towards one hash algorithm, to make

Size, speed, and simplicity were primary motivations, and the security
risks at this time are mild to non-existant - particularly given the lack
of latitude to mount attacks using the structured nature of the SPKI.

However, if you follow discussions in the CA/Browser Forum with respect to
Microsoft's plans to deprecate SHA-1, you will see that a number of CAs
have reported vendors/products that don't support SHA-256.

Now, we can discuss at length what the intersection is of (potential
implementors of PKP) and (implementations that don't support SHA-256), as
well as the potential implications of adding support for PKP but not
SHA-256 (the latter which, for FIPS validated products, would require
re-valation).

In short, I don't feel like it's a compelling reason not to include SHA-1
at this time (but am happy to see if the WG, ADs, or CFRG feel otherwise),
but I would definitely have concern over the complexity of some truncation
schemes. Example concerns with the proposal include: Is it arbitrary or is
it fixed? If it's fixed, is the criteria size of the hash? Speed of the
hash? Some other criteria?

>  HPKP-asserting sites might trigger?

Chromium does not ship versions.
Chrome, which is based on Chromium, releases new versions approximately
every six weeks. It has been successful in following the ongoing
standardization processes of a variety of specifications - in the IETF, in
the W3C, and in the WHATWG - and updating implementations accordingly and
(nearly) completely. If someone falls off the proverbial update wagon of
Chrome, they have a host of much more pressing matters - such as disclosed
security issues - that no doubt are much more concerning than the
(potential) risks of (potentially) incompatible changes.

Firefox, which has supported HSTS and is working on (shipping?) HPKP
support, is likewise on a similar update trajectory and a similar
situation where users and sites face much more pressing concerns than
HPKP.

I would think that it would be much better addressed that, as we progress
through WGLC, IF we find we need to make backwards incompatible changes,
we can assess the risks then, rather than act on hypothetical concerns in
the present.

Cheers,
Ryan

---

From: Trevor Perrin <[email-masked]>
Date: Sat, 30 Nov 2013 18:30:31 -0800

> connection (if a directive is present) and ping back.

Hmm, I assumed "report-only" pins would be noted, and the draft seems
written that way.

To step back:  It's hard to read this draft and understand how
"strict", "report-only", or "preloaded" pins should be handled.

It seems these concepts were bolted-on to the draft without being
fully integrated.  Also, processing rules are scattered throughout, so
it's hard to get a clear view of what happens during (A) processing an
HPKP header, and (B) validating a connection.

The draft could use an editing pass that doesn't change the protocol
(from the authors' understanding), but clarifies these things.

> Do you have a proposal on how to reconcile these two items?

I propose that pin expiry should be handled in the older, simpler way,
consistent with HSTS (noting a single "expiry" value).

I understand that tracking the "Effective Pin Date" was added to
support the "most recently observed" policy in 2.7.  As I've argued in
[1], I think that policy is overly complex.  There are simpler
policies which UAs should have the freedom to choose.

Anyways, maybe you could respond to [1], and we could separate out
that discussion.

> distinction between "legitimate security errors" and "pinning failures".

Pinning is risky.  Sites could make a mistake that renders them
unreachable.  This could be mitigated by "softening" UA behavior when
pin validation fails, e.g. silent-fail (with reporting), or soft-fail
(that can be clicked through) instead of hard-fail.

There are complex usability / security tradeoffs here.  I submit we
don't have enough experience with pinning to mandate a specific UI.

> have reported vendors/products that don't support SHA-256.

SHA-256 is mandatory for HPKP, so they'll have to add it.

Anyways, I suggest replacing SHA-1 with SHA-256 truncated to 128 bits.
 For example:

  Public-Key-Pins: sha256-128=<sha256-128>, sha256=<sha256>

This is simpler for the UA, as it only needs to calculate one hash on
each SPKI in the chain (instead of two).  It's also more usable for
deployers, since the same SPKI can be recognized whether it's hashed
in short or long form.  It's also more compact, and a stronger
cryptographic hash (given current state of cryptanalysis, e.g. [2]).

> (nearly) completely

Beyond just spec changes, I'd be concerned about code quality.
Chromium has had evolving code to do *something-or-other* in response
to the "Public-Key-Pins" header for over a year.

This code is a work-in-progress (in my opinion).  Some versions of it
seem like they might have problems such as applying a pin for a longer
expiry than was asserted, or with incorrect include_subdomains.

If I was a site contemplating turning on the HPKP header, this would
make me nervous.  Renaming the header seems a trivial fix to avoid any
risk here.

Trevor

[1] http://www.ietf.org/mail-archive/web/websec/current/msg01938.html
[2] https://marc-stevens.nl/research/papers/EC13-S.pdf