> Err, why isn't just validating the current certificate against fetched TLSA > records and then opening a new channel if that fails (DNS caches should be > hot) sufficient? Oops. Yes, will be good this way. > HPKP is nastier, especially in the non-pinned case. Yep, it’s the worst case. Need new channel in all case, even if not HPKP at the end. Same for proto/ciphers check. > Another interaction between connection reuse and HPKP: Potentially having to > deal with server trying to pin the reused connections (foo.example pinning > bar.example, when foo.example and bar.example share a connection). Could be tricky… It shows than connection reusage is not trivial at all, and suffer of very deep implication on TLS ecosystem and overall security. Even if fully specified, the code necessary to handle all cases correctly will just be a bunch of spaghetti and depends of hundred of parameters (some totally external to HTTP2 stack or to browser built-in features), with no insurance of better perf or (at least) same security compare to no reusage at all. -- Aeris Protégez votre vie privée, chiffrez vos communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/
Received on Friday, 2 January 2015 15:22:16 UTC