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.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to