[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sg-dc
Subject:    [Tsg] FW: [sg-dc] MS, Sun, and TLS forward secrecy (Factoring?) (fwd)
From:       Lucky Green shamrock () cypherpunks ! to
Date:       2002-03-19 18:30:08
[Download RAW message or body]

FYI:
------
	The description contained is incorrect. When using DH you do not
ever protect the key exchange with the RSA key - it is unrelated in that
area. Run "openssl ciphers -v" and read the output - Kx=RSA would suffer
from this issue.

	The real problem is that EDH-RSA-DES-CBC3-SHA isn't widely
implemented in servers and clients and this is the one that you need.
The other item is 
how often you 'roll' the DH temporary key (there is a mode in SSLeay etc
to 
do a single-use-reroll surprising called SSL_OP_SINGLE_DH_USE). By
default it is shared until you replace it ... 

	The servers public key is *not* used in the key exchange when
using DH - it would be completely pointless to do so as that would mean
you are using RSA for key exchange.

	The TLS spec has EDH+DSS+3DES as mandatory - but no one actually
uses this (SSLeay can do it but it is lightly tested) as finding DSS
signed things is a tad usual. The next rev of the TLS spec is planned to
remove the mandatory from DH and make RSA mandatory.
-------

--Lucky

> ---------- Forwarded message ----------
> Date: Wed, 27 Feb 2002 19:01:57 -0500
> From: Bruce Potter <gdead@shmoo.com>
> Reply-To: tsg@shmoo.com
> To: tsg@shmoo.com
> Subject: [Tsg] FW: [sg-dc] MS, Sun, and TLS forward secrecy 
> (Factoring?)
> 
> 
> 
> -----Original Message-----
> From: sg-dc-admin@securitygeeks.com 
> [mailto:sg-dc-admin@securitygeeks.com] On Behalf Of Peter Watkins
> Sent: Wednesday, February 27, 2002 6:20 PM
> To: sg-dc@securitygeeks.com
> Subject: Re: [sg-dc] MS, Sun, and TLS forward secrecy (Factoring?)
> 
> 
> I got an off-list request to expand on this bit, so here goes:
> 
> > > So if DJB's findings threaten 1024 bit RSA SSL/TLS server keys,
> > > online commerce could be effed up big time, in which case I'd be 
> > > quite happy if the public finally realized what MSFT and 
> SUNW have 
> > > been doing to the attempts of many IETF TLS working group members 
> > > who would like to offer best practice security...
> 
> If you record a stream of SSL/TLS traffic that uses "strong" 
> RSA ciphers and you possess the server's RSA key, you can 
> decrypt the stream with that key. This is not true of "weak" 
> "export" RSA ciphers for SSL/TLS, but the spec prohibits 
> using large keys in "export" grade communications, so the 
> fact that the "export" cipher provides "forward secrecy" is 
> moot.[0] So an attacker could record Amazon's https:// 
> traffic all year long, and if they could somehow obtain their 
> server keypair at any time, then decrypt all "strong" traffic 
> that used the
> keypair(s) the attacker obtained. With forward secrecy (as in 
> the "export" ciphersuites), an attacker could pose as Amazon 
> after stealing their key (assuming Amazon did not notice and 
> revoke the key) but the attacker could *not* decrypt past 
> traffic, which is IMO the way it should be. But with the 
> current infrastructure & specs, if Amazon has a single key, 
> replaces it every New Years', and either doesn't realize the 
> key is compromised, or the key is compromised on Christmas 
> day, then basically a full year of "secure" communication can 
> be unlocked as soon as their RSA key is obtained by an attacker.
> 
> Every time (or so it seems) individuals on the TLS working 
> group mailing list have proposed requiring that TLS systems 
> should support ciphersuites that provide forward secrecy 
> (especially "perfect" forward secrecy, where every connection 
> uses a different temporary key), representatives from 
> Microsoft and Netscape/Sun have made it clear that their 
> employersthink "strong" / zero-forward-secrecy algorithms are 
> computationally expensive enough as is, and for performance's 
> sake are unwilling to accept requirements that might make the 
> servers' work more difficult. Mobile device vendors (think 
> cell phones) are also concerned about performance, but they 
> seem to put up less of a fight than SUNW/MSFT. Basically it 
> seems that SUNW/MSFT believe they have veto power. The 
> working group seems to fear that "asking too much" of 
> Microsoft will push MSFT to implement a non-standard, 
> non-compliant TLS codebase, and that may weaken the TLS 
> working group's ability to guide future development. All of 
> this is of course very much my read of the situation.
> 
> Yes, this all seems very crazy to me. The SSL/TLS server 
> could generate a temporary RSA key, and sign it, every six 
> hours or so -- posing nearly zero additional cost on the 
> server. But a six hour lifespan would mean an attacker 
> wanting to decrypt traffic would now have to attack the 
> server memory (the temporary key would never need to be 
> written to disk)
> -- dumpster diving for backup tapes would no longer suffice. 
> And any compromise would have a very limited scope, just the 
> clients who connected while that temporary key was in use. 
> The MSFT/SUNW opposition seems insane to me. Especially from 
> Microsoft, since their products typically run on x86 hardware 
> which is now reasonably good at public key crypto operations. 
> Many parties have a vested interest in promoting the image of 
> SSL/TLS as magic security pixie dust, but the truth is that 
> it's not as good/strong/safe as it could be, and the 
> cryptographers know it.
> 
> -Peter
> 
> [0] The basic deal is this. The SSL/TLS session key is derived from a 
> client-provided secret. The client, after getting the 
> server's RSA key and 
> presumably checking the identity-verifying certificate, 
> encrypts the secret 
> with the server's public RSA key and sends it along. So 
> anyone with a copy 
> of the server private key can read the secret, deduce the 
> session key, and 
> decipher the stream, even long after the fact. (This makes Verisign's 
> marketing of two-year server certificates a pretty dubious 
> move.) Export RSA 
> ciphersuites don't have this problem. With the export suites, 
> the server
> 
> generates a temporary RSA keypair, signs the temporary public 
> key with its 
> permanent private key, and sends the temporary public key, 
> permanent public 
> key, and permanent key cert. The client verifies that the 
> permanent public 
> key looks OK, and the temporary public key was signed by the 
> permanent, 
> certified private key. It then encrypts the secret for the 
> temporary public 
> key. An eavesdropper who possesses the full server permanent 
> keypair would 
> still not be able to deduce the temporary private RSA key 
> from the traffic, 
> and therefore could not decipher the encrypted 
> client-provided secret, and 
> therefore is out of luck.





[prev in list] [next in list] [prev in thread] [next in thread]