On Mon, Jun 24, 2013 at 6:30 PM, Tobias Gondrom <[email protected]>wrote:
> On 25/06/13 05:06, Trevor Perrin wrote: > > > On Mon, Jun 24, 2013 at 12:01 AM, Tobias Gondrom < > [email protected]> 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
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
