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