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

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. 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.  Another think to consider is HTTP/2, where the header compression is not yet specified, but the algorithm that is currently being discussed on the mailing list has the ability to reference headers from previous responses, so that the full Public-Key-Pin could be included only once, and referred back to in other responses, although that's not really necessary.

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.

What do others think?

Yoav

On Jun 20, 2013, at 9:55 PM, David Matson <dmatson@microsoft.com<mailto:dmatson@microsoft.com>> wrote:

I sent the mail below to the draft-ietf-websec-key-pinning-06 authors, and Chris Palmer suggested I raise the points on this mailing list. He also mentioned a previous discussion (which I haven’t been able to locate) around a well-known host security information URL; if there’s a good place to get up to speed on that discussion, a pointer would be much appreciated.

Thanks,

David

I really like the overall approach taken in Public Key Pinning Extension for HTTP (draft-ietf-websec-key-pinning-06). Particularly, the public key (including algorithm) seems like exactly the right thing to pin.

A couple of thoughts on other areas of the draft (my apologies if these have been discussed before elsewhere; I’m only familiar with the draft text):

1. It would be nice to avoid including full public key data with every HTTP response. Particularly if there are multiple public keys in use, there’s a bit of potential data overhead on every response. Would it make more sense to have the public key data in a separate resource? As a first step, perhaps having every resource just have a pointer, using a header something like the following:
Public-Key-Pin-Location: /pins
Where “/pins” would be a separate resource that would have Public-Key-Pins header data.
Or, to go one step further, this data could then appear in the entity-body (perhaps in JSON format) and use normal HTTP resource-level mechanisms—for example, using Cache-Control to specify the expiration rather than a custom max-age header directive.

2. It would be nice to have the public key specified in a central place for the host, rather than by any resource, since the public keys are at the TLS level and don’t vary per resource. I’m not sure there’s an ideal solution here, but a couple of options might be:
a. Have a fixed, well-known resource per host for retrieving public key pin data (such as “/well-known-pins” or something like that).
b. An OPTIONS * request might be a good fit here, it was apparently intended for server-level information. Perhaps the response to an OPTIONS * could have the public key data (like the Public-Key-Pins header). Alternatively, to combine the two ideas, the OPTIONS * response could, instead of having the public key data itself, instead have a header with a URL for a public key pins resource (like the Public-Key-Pin-Location header mentioned above).

Thanks for considering these ideas.

Email secured by Check Point

_______________________________________________
websec mailing list
websec@ietf.org<mailto:websec@ietf.org>
https://www.ietf.org/mailman/listinfo/websec