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

[Tobias Gondrom <[e-mail]>]

On 25/06/13 05:06, Trevor Perrin wrote:
>
> On Mon, Jun 24, 2013 at 12:01 AM, Tobias Gondrom
> <[e-mail] <mailto:[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.)

No I am not suggesting to send both hashes. That would be unnecessary
and of very use.
So that means: 2 keys (the main key and the backup key) with one hash
each (SHA-160 OR SHA-256 OR SHA-512 OR ...)
Looking back at the discussions my perception is that in the case of
many (though not all) implementations the server will have only one key
active at the point of entry and then use a reverse proxy.
(with a caveat: I remember one large bank that seems due to whatever
historic reason is actually using different certificates for every
singly server instance, which obviously could then go into the 100s or
1000s.... - but I don't worry about this too much as AFAIK this was more
duet to misunderstanding regulation and a stupid architecture - so will
just need to clean up before they can go to pinning - which is fair in
my eyes.)



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

I see. From my humble experience, I would agree with Chris (in his later
email) and don't see a performance problem with this. So I don't think
we need to consider the URI option.

Best regards, Tobias


>
>
> Trevor