Then again, NULL-NULL-NULL wouldn't exactly give any kind of SSL bonus, and would cause additional protocol overhead.
Unless I'm wrong? Correct me, here, guys?
I don't see much to correct. The biggest overhead by large is indeed the initial public key checking (that's mostly on the client though).
And after handcheck, mac calculation is often quite as computation intensive as the encryption. Not when you use 3DES, but for example so much effort has been done on AES that it tends to be faster than SHA-1 in most implementation.
The biggest gain for a server is to make sure it's session cache will keep all opened session for a large time. Even when the client closed the TCP connexion, he can negociate with the server to reuse the old session when opening a new one, and avoid fully the computation intensive part of the authentification. But that only goes so far.
I've seen recently that the way Thunderbird/Firefox check for update to the browser or to extensions is through an SSL connexion to addons.mozilla.org. There's then a DNS round-robbin to redirect to several OSU OSL's machines.
That's typically a case where we would like to make whatever is possible to reduce the load on the servers, given the number of deployed client that will check on it, but it will be very difficult.
The connexion are too sparse to reuse the connexion information.
What's more with the round-robbin, you will redirect to several different servers so you won't be able to reuse sessions. One can try to memorize the value returned to a given client IP and always return the same later to avoid that problem.
After the discussion on signed extension and the best way to check for their revocation information, I've been thinking that maybe the best would be to do away with both CRL or OCSP and just use the same mechanism as for the updates (that would be conceptually equivalent to OCSP).
But I'm not sure the mechanism for update upscales that greatly ...
Maybe the best method would be to use regular HTTP connexion, and to sign the information distributed, so that you can easily dispatch to more servers.
That still don't mean you could use Bouncer, because the size of the redirect exchanged with Bouncer will not be unsignificant WRT the size of the signed answer. So you should use DNS redirection. Maybe you could generate the name of the host to address based on the extension/executable to check for so that load repartition becomes easier ?
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
