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