On Thu, Sep 30, 2010 at 01:36:47PM -0400, Paul Wouters wrote: [I wrote]: >> Also, consider devices such as deep-inspection firewalls or application >> traffic managers which must by their nature offload SSL processing in >> order to inspect and possibly modify data > > You mean it will be harder for MITM attacks on SSL. Isn't that a good thing? > :P
No, I don't mean that, because if the administrator of site _X_ decides to do SSL processing on a front-end device instead of on the HTTP servers, for whatever reason, that is simply not a MITM attack. To characterize it as one is basically obfuscatory. When I talk about "SSL everywhere" being an immediate opportunity, I mean that, from my point of view, it looks like there's a growing realization that _for current key sizes and server workloads_, for many high transaction rate sites like Gmail, using SSL is basically free -- so you might as well, and we all end up better off. Mutliplying the cost of the SSL session negotiation by a small factor will change that for a few sites, but multiplying it by a factor somewhere from 8 to 11 (depending on different measurements posted here in previous discussions) will change it for a lot more. That's very unfortunate, from my point of view, because I believe it is a much greater net good to have most or almost all HTTP traffic encrypted than it is for individual websites to have keys that expire in 3 years, but are resistant to factoring for 20 years. The balance is just plain different for end keys and CA keys. A one-size-fits-all approach using the key length appropriate for the CA will hinder universal deployment of SSL/TLS at the end sites. That is not a good thing. Thor --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com