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

[Trevor Perrin <[e-mail]>]

On Mon, Jun 24, 2013 at 12:01 AM, Tobias Gondrom <[e-mail]
> wrote:

>
> On 24/06/13 09:13, Trevor Perrin wrote:
>
>  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.
>

I don't know what the common case would be.  The numbers I cited are from
the Chromium's preloaded key pins:

https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json

Note that a commercial CA might have several subordinate and root
certificates, with different keys.  To pin yourself to this CA, you may
need to list several of these keys, and to be conservative a site might pin
multiple CAs.

(Are you suggesting that sites would list both a SHA256 and SHA1 hash for
each pinned key?  That seems unnecessary.)



> Just for my understanding: Do you think this will create too much header
> overhead and there want to the reference to the pin?
>

I don't know how much data a site could add to every HTTP Response before
it starts becoming a problem.  But that's the issue David raised.

If it's a real problem, the idea of putting pin assertions in, say, a JSON
file at a "well-known" URI seems reasonable.  E.g.:

http://www.example.com/.well-known/public-key-pins


Trevor