On Sun, Jun 23, 2013 at 12:25 AM, Yoav Nir <[email protected]> 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
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
