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

[Trevor Perrin <[e-mail]>]

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

>  Hi David
>
>  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".
>
>  Looking at the examples in the key-pinning draft, an HPKP header using
> SHA-1 takes just under 120 bytes.
>

Depends on the number of pinned keys.  Chrome's existing preloads [1] have
9, 5, 19, 36, 2, and 2 keys.  That's a mean of 12, which would be >500
bytes with SHA256.



>  Compared to some of the stuff that gets sent in HTTP headers (I'm looking
> at you, user-agent) this is pretty tame. 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.
>

I thought so too, but draft-04 and later say:

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

So apparently it *does* need to be sent on every response, to maintain the
pin?


Still, I can see several merits in your proposal:
>  - clients that don't support key pinning need not get a header they're
> not going to process
>  - Inserting a header only in the first response requires information from
> the TLS layer, so it's easier to just insert the header in every response.
>  - HTTP/2 is not yet here, let alone wide-spread.
>

Agreed it has merit, particularly if there's any possibility of future
pinning policies growing larger with other types of data (e.g. policies for
error-handling and reporting, or "pinning" to other things like CT, DNSSEC,
TACK, etc...)


Trevor