Re: [websec] Comments on draft-ietf-websec-key-pinning-06

[Chris Palmer <[e-mail]>]

On Sun, Jun 23, 2013 at 12:25 AM, Yoav Nir <[e-mail]> wrote:

> As far as I know, this idea was not discussed before. If we were to do this,
> the proper URI for this would be some kind of RFC 5785 URI like
> "/.well-known/pins" or "/.well-known/hpkp".

I think it has been brought up in another forum; Ryan Sleevi will know
better than I.

> Looking at the examples in the key-pinning draft, an HPKP header using SHA-1
> takes just under 120 bytes. Compared to some of the stuff that gets sent in
> HTTP headers (I'm looking at you, user-agent) this is pretty tame.

Not to mention the body. :)

> Moreover,
> the key-pinning header does not have to be sent in every response - it's
> enough to send it once per full TLS handshake.

Actually, we ended up changing that, a while back now. From the current draft:

"""
2.2.1. HTTP-over-Secure-Transport Request Type

   When replying to an HTTP request that was conveyed over a secure
   transport, a Pinned Host SHOULD include in its response exactly one
   PKP header field that MUST satisfy the grammar specified above in
   Section 2.1.  If the Pinned Host does not include the PKP header
   field, and if the connection passed Pin Validation, UAs MUST treat
   the host as if it had set its max-age to 0 (see Section 2.3.1).
"""

In most realistic web application scenarios, even sending an HPKP
header on every response is likely to have negligible impact on
overall application performance. Almost every web application I have
seen has much lower-hanging fruit for performance optimization.