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

Hi all,

<no hat>
comments inline.
Best regards, Tobias

On 24/06/13 09:13, Trevor Perrin wrote:
>
> On Sun, Jun 23, 2013 at 12:25 AM, Yoav Nir <ynir@checkpoint.com
> <mailto:ynir@checkpoint.com>> 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.
>

IMHO the expected session will be 2 keys with SHA-160 to SHA-512 per host.
Just for my understanding: Do you think this will create too much header
overhead and there want to the reference to the pin?

>  
>
>     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?

Yes. That is my reading of the paragraph, too. I guess the assumption
was that this shall function as a fail safe instead of actively setting
it to value 0.

>
>
>     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
>
>
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec