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

[Trevor Perrin <[e-mail]>]

On Mon, Jun 24, 2013 at 6:30 PM, Tobias Gondrom
<[e-mail]>wrote:

>  On 25/06/13 05:06, Trevor Perrin wrote:
>
>
>  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.)
>
>
> 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 ...)
>

You're ignoring pinning to CAs, which is a major use case for HPKP.



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

A single hostname could be using different SSL keys at the same time for
various reasons, e.g. in-progress key changes, geographically distributed
servers, HSM limitations, CDNs, etc.

So you can't ignore this case quite so easily.  It's one of the reasons I
prefer pinning signing keys to pinning SSL keys.


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

OK.


Trevor