[145939] in cryptography@c2.net mail archive
Re: 2048 bits, damn the electrons! [rt@openssl.org: [openssl.org
daemon@ATHENA.MIT.EDU (Thor Lancelot Simon)
Thu Sep 30 20:53:30 2010
Date: Thu, 30 Sep 2010 14:16:31 -0400
From: Thor Lancelot Simon <tls@rek.tjls.com>
To: cryptography@metzdowd.com
In-Reply-To: <alpine.LFD.1.10.1009301333250.25946@newtla.xelerance.com>
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 majordomo@metzdowd.com
