Subject: [TLS] Security today

From: Mike <[email-masked]>
Date: Thu, 27 Mar 2008 16:15:01 -0700

Is anyone else concerned about the level of security on the
Internet today?  I mean everybody is using 1024-bit RSA keys
which have an estimated 80 bits of security.  (Yet CA's are
happy to claim that you get 128 or even 256 bits of security
using them for SSL.)  RSA Labs even states that 1024-bit keys
are good only until 2010, and they estimate 2048-bit keys
will protect data until 2030.  Why use such small margins
anyway?  Processors are already super fast and getting even
faster.  Who cares if it takes an extra half second to buy a
book if your financial data will be secure for several more
decades?

Not only will 1024-bit keys be broken "soon", but when that
happens, it's not just a matter of replacing keys -- any data
transmitted over a channel using plain RSA key exchange has
no forward secrecy, and is thus exposed.  An added problem is
that lots of websites will purposely ignore higher-security
cipher suites (that do provide forward secrecy) early in the
cipher list and choose RSA_WITH_RC4 preferentially, probably
because it is slightly faster.  Even more fuel to the fire is
the fact that many websites have disabled DHE_* cipher suites
in the past few months (I thought my TLS test client was
broken because sites that I used to connect to with DHE no
longer negotiate it).

What will it take to affect a change in this state of affairs
that treats 1024-bit keys as secure?

Mike
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Michael Howard <[email-masked]>
Date: Thu, 27 Mar 2008 16:59:15 -0700

I think there is a deeper issue than this - people email sensitive data all the time with no encryption...

Cheers, Michael
Writing Secure Code for Windows Vista: http://www.microsoft.com/MSPress/books/10723.aspx
SDL Book: http://www.microsoft.com/MSPress/books/8753.asp
Blog: http://blogs.msdn.com/michael_howard/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike
Sent: Thursday, March 27, 2008 6:15 PM
To: [email-masked]
Subject: [TLS] Security today

Mike

---

From: Benjamin Black <[email-masked]>
Date: Thu, 27 Mar 2008 19:13:20 -0700

"People" do all manner of things with poor security.  The people who  
are, or should be, experts, however, should do better.  I believe  
Mike's point is that not only do they often not do better, they are  
actually doing better less then before (apologies for the horror of  
that syntax).

Ben

---

From: Mike <[email-masked]>
Date: Thu, 27 Mar 2008 19:27:46 -0700

Michael Howard wrote:
> I think there is a deeper issue than this - people email
> sensitive data all the time with no encryption...

Yes, email security is problematic, but users have to do
a lot of manual configuration even to get set up for it.
And then, they need to convince their correspondents to
set up their system too.

With HTTPS, the infrastructure is already there, and it's
being used.  The problem is with server configuration:
key size, cipher suite selection.  If servers were simply
better configured, security would automatically improve.
Users wouldn't have to do anything differently; those
who we rely on for security are failing us!

Mike

P.S. and there's nothing you or I can do about it as a
user -- we can't influence the key sizes or cipher suites
offered by a server -- it's either take it or leave it.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Michael Howard <[email-masked]>
Date: Thu, 27 Mar 2008 20:31:14 -0700

Fwiw, at Microsoft we mandate the use of "strong crypto" and that includes ciphersuites and bit lengths. In the case of RSA, 2048 minimum, and the only time 1024 is allowed is for backward compat, and that has to be signed off by the crypto board (Ferguson, LaMacchia, Benoloh et al)

Cheers, Michael

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike
Sent: Thursday, March 27, 2008 9:28 PM
To: [email-masked]
Subject: Re: [TLS] Security today

Mike

---

From: Rodney Thayer <[email-masked]>
Date: Fri, 28 Mar 2008 09:32:27 -0800

> offered by a server -- it's either take it or leave it.

(In a struggle to bring the thread back to tls-relevance...)

in theory you're supposed to look at the cert and it's cps
(which is referenced in a field in the cert in the payload
in the TLS protocol...) and the ciphersuite selection and
refuse to connect.

In other words, the protocol supports you deciding to
not interact with the server.

If your wireless service vendor uses 40 bit rc-4 and
an expired 1024 bit cert then one could reasonably
ask why you trust them ;-)

Since many of these TLS connections are being used
by trading partner users you CAN do something about it -
you can act like a trading partner and refrain from
doing business with people who run sloppy servers.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Mike <[email-masked]>
Date: Fri, 28 Mar 2008 13:16:14 -0700

> (In a struggle to bring the thread back to tls-relevance...)

In my opinion, this is very relevant to TLS.  TLS is being
mis-used so badly, that security is unnecessarily horrible.
TLS itself is not bad, but if (when) something bad happens,
it will be blamed for being insecure.  You don't want that
to happen.

I think that it's become necessary for the TLS WG to put
together a document with hard numbers in it for key lengths,
relative strengths, expected lifetime for data protected by
those keys/lengths/algorithms.  Of course the IETF doesn't
want to take on the liability associated with recommending
any particular algorithms/key lengths, but they can easily
recommend against those that are believed to be weak.  There
is plenty of public information that can be referenced (from
multiple sources) to avoid taking on liability.

With this document out there, those who are afraid to do
anything better than what everybody else is doing (opening
themselves up to being fired if something goes wrong), will
be able to take some initiative to improve the situation.
And with this information out there, they won't be able to
simply say that they were just following the herd.

I don't consider myself expert enough to take on this task,
but I know that others on this list are expert enough.

> in the TLS protocol...) and the ciphersuite selection and

In theory, yes.  But who ever looks at a CPS?  I don't even
know how to get Firefox to show it to me, and no ordinary
user even knows that CPS's exist.

> not interact with the server.

If there was a local Amazon.com bookstore in my neighborhood,
you can bet I would follow this advice.

Mike

---

From: Yoav Nir <[email-masked]>
Date: Sat, 29 Mar 2008 00:12:49 +0300

> book if your financial data will be secure for several more

RSA labs' estimate seems a little pessimistic to me, as there has been  
a 64-bit attack on SHA-1 for 2 years and even the original researchers  
haven't got the computing resources to mount it. Sure, the NSA might  
be able to do it, but not your average hacker, competitor or  
moderately-sized botnet.  Given that, I don't see how we scale to 80- 
bits in two years.

Still, Amazon does not make its own certificates. It buys them from  
Verisign or some other commercial CA. That vendor sells them the 1024- 
bit RSA certificate, and nearly every web server certificate I've ever  
seen is 1024-bit (I did see once a 1000-bit key on some site - who  
needs powers of two, anyway?)  I don't know how the negotiation  
between Amazon and Verisign goes, but from both parties' points of  
view, this would require Amazon to use more computing resources (half  
a second is cheap to you, but expensive for a web server - they care),  
or IOW upgrade their server farm. A moderate expense for zero  
perceived security benefits - it won't stop any attacks.

Nor can browser makers enforce minimal security - you don't want to  
make a browser that won't work with Amazon.

I don't think the IETF is the right body for a document such as you  
propose. The admin at Amazon does not read the new RFC list to check  
whether their certificate is still "good enough". I'm not sure what  
the right body is, NIST is probably the one for the US, but even they  
tend to make recommendations only for government bodies.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Mike <[email-masked]>
Date: Fri, 28 Mar 2008 17:49:34 -0700

> RSA labs' estimate seems a little pessimistic to me, as there has been a 
> 64-bit attack on SHA-1 for 2 years and even the original researchers 
> haven't got the computing resources to mount it. Sure, the NSA might be 
> able to do it, but not your average hacker, competitor or 
> moderately-sized botnet.  Given that, I don't see how we scale to 
> 80-bits in two years.

Even if it's 10 years or 20, why have such a small security margin?
Plus I believe that part of the lifetime estimate takes into account
the expected advances in factoring methods.

Put another way, if someone came to you and said they needed to
protect millions of transactions worth billions of dollars, would
you suggest 1024-bit RSA with RC4/MD5?  That's the reality we live
in today.

> Verisign or some other commercial CA. That vendor sells them the 
> 1024-bit RSA certificate, and nearly every web server certificate I've 
> ever seen is 1024-bit (I did see once a 1000-bit key on some site - who 
> needs powers of two, anyway?)  I don't know how the negotiation between 
> Amazon and Verisign goes, but from both parties' points of view, this 
> would require Amazon to use more computing resources (half a second is 
> cheap to you, but expensive for a web server - they care), or IOW 
> upgrade their server farm. A moderate expense for zero perceived 
> security benefits - it won't stop any attacks.

The problem is that Amazon (and I'm not picking on Amazon, just using
them as an example) is making the decision that my privacy is not as
important as pumping transactions through.  As a customer, I don't
have any way to say that I want them to do better.  There are no
parameters in TLS whereby the client can specify minimum acceptable
key lengths, for example.  The expensive (to Amazon) half second they
save by using a small RSA key is expensive to me in that my financial
information is not as well protected as I want - I care.  I'll gladly
pay 5 cents security infrastructure tax to Amazon for every transaction
I complete using better security.

This touches on a point I made months ago that it would be easy to
add an extension to TLS whereby a client could specify minimum key
lengths.  It was rejected by many who said it "would only provide a
false sense of security."  Well I never believed them, and now that
I've read Practical Cryptography by Schneier and Ferguson, and see
that in the key exchange protocol that they develop the very first
thing Alice sends to Bob is her minimum key length requirement, I
know that it is not a stupid idea!

> Nor can browser makers enforce minimal security - you don't want to make 
> a browser that won't work with Amazon.

No, but if TLS supported a mechanism for the client to specify some
of the security parameters (minimum RSA key size, DH p and q, etc.),
then their systems could use the less secure keys by default and
only pull out the big guns when someone explicitly asks for them.

> whether their certificate is still "good enough". I'm not sure what the 
> right body is, NIST is probably the one for the US, but even they tend 
> to make recommendations only for government bodies.

Do you really want to get the government involved?  Amazon's admin
may not read the latest RFC's, but probably Verisign's does, and
when Amazon's certificate expires, they can be enticed to upgrade
to a larger key, and even pointed to the RFC which would help them
choose better cipher suites (e.g. DHE_RSA_XX).

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Mar 2008 18:08:04 -0700

At Fri, 28 Mar 2008 13:16:14 -0700,
Mike wrote:
> those keys/lengths/algorithms.

RFC 3766.

-Ekr

---

From: Benjamin Black <[email-masked]>
Date: Fri, 28 Mar 2008 18:42:37 -0700

That might be the case for box products.

$ openssl s_client -connect www.microsoft.com:443 -tls1
CONNECTED(00000003)
depth=2 /CN=Microsoft Internet Authority
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
  0 s:/C=US/ST=washington/L=Redmond/O=Microsoft/OU=mscom/CN=www.microsoft.com
    i:/DC=com/DC=microsoft/DC=corp/DC=redmond/CN=Microsoft Secure  
Server Authority
  1 s:/DC=com/DC=microsoft/DC=corp/DC=redmond/CN=Microsoft Secure  
Server Authority
    i:/CN=Microsoft Internet Authority
  2 s:/CN=Microsoft Internet Authority
    i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE  
CyberTrust Global Root
---
Server certificate
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
subject=/C=US/ST=washington/L=Redmond/O=Microsoft/OU=mscom/CN=www.microsoft.com
issuer=/DC=com/DC=microsoft/DC=corp/DC=redmond/CN=Microsoft Secure  
Server Authority
---
No client certificate CA names sent
---
SSL handshake has read 4078 bytes and written 284 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 1024 bit
SSL-Session:
     Protocol  : TLSv1
     Cipher    : AES128-SHA
     Session-ID:  
531400000548600BCAE3CC4838956A1C3050A9CF2F0B201FD2CBEA4E9F473AB0
     Session-ID-ctx:
     Master-Key:  
2700AA7DF91BEA3B007FE14D3B2289ED0F5041E99044410A6A4B8A657E916D21451B738AEFA68992EB24E8B19A0A9E30
     Key-Arg   : None
     Start Time: 1206754788
     Timeout   : 7200 (sec)
     Verify return code: 20 (unable to get local issuer certificate)
---
DONE
$

On Mar 27, 2008, at 8:31 PM, Michael Howard wrote:
> Fwiw, at Microsoft we mandate the use of "strong crypto" and that  
> includes ciphersuites and bit lengths. In the case of RSA, 2048  
> minimum, and the only time 1024 is allowed is for backward compat,  
> and that has to be signed off by the crypto board (Ferguson,  
> LaMacchia, Benoloh et al)
>
> Cheers, Michael

---

From: Michael Howard <[email-masked]>
Date: Fri, 28 Mar 2008 18:51:18 -0700

>> That might be the case for box products.

That's exactly what our group does - "box" products

-----Original Message-----
From: Benjamin Black [mailto:[email-masked]] 
Sent: Friday, March 28, 2008 8:43 PM
To: Michael Howard
Cc: Mike; [email-masked]
Subject: Re: [TLS] Security today

  0
s:/C=US/ST=washington/L=Redmond/O=Microsoft/OU=mscom/CN=www.microsoft.com
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
subject=/C=US/ST=washington/L=Redmond/O=Microsoft/OU=mscom/CN=www.microsoft.
com
issuer=/DC=com/DC=microsoft/DC=corp/DC=redmond/CN=Microsoft Secure
Server Authority
---
No client certificate CA names sent
---
SSL handshake has read 4078 bytes and written 284 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 1024 bit
SSL-Session:
     Protocol  : TLSv1
     Cipher    : AES128-SHA
     Session-ID:
531400000548600BCAE3CC4838956A1C3050A9CF2F0B201FD2CBEA4E9F473AB0
     Session-ID-ctx:
     Master-Key:
2700AA7DF91BEA3B007FE14D3B2289ED0F5041E99044410A6A4B8A657E916D21451B738AEFA6
8992EB24E8B19A0A9E30
     Key-Arg   : None
     Start Time: 1206754788
     Timeout   : 7200 (sec)
     Verify return code: 20 (unable to get local issuer certificate)
---
DONE
$

On Mar 27, 2008, at 8:31 PM, Michael Howard wrote:
> Writing Secure Code for Windows Vista:
http://www.microsoft.com/MSPress/books/10723.aspx

---

From: Mike <[email-masked]>
Date: Fri, 28 Mar 2008 21:14:30 -0700

>> those keys/lengths/algorithms.

Thanks for the pointer to that document; I hadn't seen it before.
However, the document I think we need would merely use that RFC
as a (important) reference.  In particular it doesn't mention
TLS at all or its key exchange mechanisms.  It also seems to be
written for cryptographers, not your average programmer.

The things that I think need to be spelled out are things like
forward secrecy.  For example, the RSA key for an RSA_* cipher
suite needs to be much stronger than the RSA key for DHE_RSA_*
since breaking the latter doesn't reveal anything about any
past sessions, while breaking the former reveals everything
about every past session.

Also after breaking the key, you can passively listen in on any
future sessions based on RSA_* without much risk of detection,
but to get anything out of future DHE_RSA_* sessions, you need
to actively insert yourself in the middle.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Mar 2008 21:20:43 -0700

At Fri, 28 Mar 2008 21:14:30 -0700,
> to actively insert yourself in the middle.

This is all well-known material amply covered in the cryptographic
literature. I don't see any benefit in the TLS WG rehashing
this territory.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Mar 2008 21:25:20 -0700

At Fri, 28 Mar 2008 21:20:43 -0700,
> literature. I don't see any benefit in the TLS WG rehashing

For that matter, much of it is in "SSL and TLS: Designing and
Building Secure Systems"

-Ekr

---

From: Yoav Nir <[email-masked]>
Date: Sat, 29 Mar 2008 18:03:20 +0300

> you suggest 1024-bit RSA with RC4/MD5?  That's the reality we live

We do trust this. You mention having read books by Schneier. No doubt  
you've come across the parable of the 50-foot pole. 1024-bit RSA with  
RC4 and HMAC-MD5 may not be the best cryptography we have today, but  
it's enough that no attacker to date has targeted the cryptography.  
All hacking and cracking you hear about is done without any attempt at  
cryptanalysis. Rather, it's done through poor database permissions,  
poor input sanitizations or social engineering.

Sure, I'd love everyone to move to 4096-bit RSA or the ECC eqivalent,  
along with AES-256 and HMAC-SHA-256, but I don't think you can point  
to any attacks that this would stop. In particular, it wouldn't save  
this schools records:
http://xkcd.com/327/

If you've read the recently-published IAB draft about what makes a  
successful protocol, then yes, it looks like government intervention  
is the best way to push forward more secure cryptography. Even a non- 
binding standard for e-commerce would more likely than not push  
certificate vendors to comply. In the meantime, browsers could add  
visual indications for the cryptography strength, but that's nothing  
the IETF should standardize.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Benjamin Black <[email-masked]>
Date: Fri, 28 Mar 2008 18:59:20 -0700

Exactly.  Meanwhile, Mike's point is about the certificates people  
purchase from the CAs and the configurations on "secure" web servers.   
IE "defaulting" to strong crypto mechanisms helps not at all when the  
servers offer up certificates with short keys and weak algorithms.   
Think outside the box ;)

On Mar 28, 2008, at 6:51 PM, Michael Howard wrote:
> MIIGJjCCBQ6gAwIBAgIKPuTDHAAEAACvkDANBgkqhkiG9w0BAQUFADCBizETMBEG
> CgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1pY3Jvc29mdDEUMBIG
> CgmSJomT8ixkARkWBGNvcnAxFzAVBgoJkiaJk/IsZAEZFgdyZWRtb25kMSowKAYD
> VQQDEyFNaWNyb3NvZnQgU2VjdXJlIFNlcnZlciBBdXRob3JpdHkwHhcNMDgwMjEy
> MTgyNTE4WhcNMDkwMjExMTgyNTE4WjB0MQswCQYDVQQGEwJVUzETMBEGA1UECBMK
> d2FzaGluZ3RvbjEQMA4GA1UEBxMHUmVkbW9uZDESMBAGA1UEChMJTWljcm9zb2Z0
> MQ4wDAYDVQQLEwVtc2NvbTEaMBgGA1UEAxMRd3d3Lm1pY3Jvc29mdC5jb20wgZ8w
> DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALbG21smSr8rN+qJ5al2ml5BaPlBnyuK
> gN6KOS8TGTde496kil72zBF70sgRhQCERNNAiH0XaNWbDSqXcoxySOQhhW4PJ9P3
> OfSNQMBbG+8tVFsyk12cZZSQGK7iE6Wy1mAvsbZ0K1iCvg5DceSDRgc7sggKcVi5
> ZyS4wRwIlgI1AgMBAAGjggMkMIIDIDALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYI
> KwYBBQUHAwIGCCsGAQUFBwMBMHgGCSqGSIb3DQEJDwRrMGkwDgYIKoZIhvcNAwIC
> AgCAMA4GCCqGSIb3DQMEAgIAgDALBglghkgBZQMEASowCwYJYIZIAWUDBAEtMAsG
> CWCGSAFlAwQBAjALBglghkgBZQMEAQUwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYD
> VR0OBBYEFIfqPJz0gndqvXIFZOP8H0+b2XKBMB8GA1UdIwQYMBaAFJmPpfcegW/6
> ecLwFj+yVLEIaEdVMIIBCgYDVR0fBIIBATCB/jCB+6CB+KCB9YZYaHR0cDovL21z
> Y3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9jcmwvTWljcm9zb2Z0JTIwU2Vj
> dXJlJTIwU2VydmVyJTIwQXV0aG9yaXR5KDQpLmNybIZWaHR0cDovL2NybC5taWNy
> b3NvZnQuY29tL3BraS9tc2NvcnAvY3JsL01pY3Jvc29mdCUyMFNlY3VyZSUyMFNl
> cnZlciUyMEF1dGhvcml0eSg0KS5jcmyGQWh0dHA6Ly9jb3JwcGtpL2NybC9NaWNy
> b3NvZnQlMjBTZWN1cmUlMjBTZXJ2ZXIlMjBBdXRob3JpdHkoNCkuY3JsMIG/Bggr
> BgEFBQcBAQSBsjCBrzBeBggrBgEFBQcwAoZSaHR0cDovL3d3dy5taWNyb3NvZnQu
> Y29tL3BraS9tc2NvcnAvTWljcm9zb2Z0JTIwU2VjdXJlJTIwU2VydmVyJTIwQXV0
> aG9yaXR5KDQpLmNydDBNBggrBgEFBQcwAoZBaHR0cDovL2NvcnBwa2kvYWlhL01p
> Y3Jvc29mdCUyMFNlY3VyZSUyMFNlcnZlciUyMEF1dGhvcml0eSg0KS5jcnQwPwYJ
> KwYBBAGCNxUHBDIwMAYoKwYBBAGCNxUIg8+JTa3yAoWhnwyC+sp9geH7dIFPg8Lt
> hQiOqdKFYwIBZAIBBTAnBgkrBgEEAYI3FQoEGjAYMAoGCCsGAQUFBwMCMAoGCCsG
> AQUFBwMBMA0GCSqGSIb3DQEBBQUAA4IBAQAztULGfaAxeoGZbbViAVMtaPkMHaoN
> wGzhw4ePcWqSvDKnl9yLpbAsl7T+w4bbeJotXCl89Ri+G4Mbfo3wzcDfStM66qcR
> zGnEpiESh7cUZhUrxo+Iu+Ptn3pR/ub3uv8/WwF+KK6UUP+uhVMyxPT2LaGWgBSd
> 9/8qtngpMAbQVKnm4D8uQrcOa4Yqnjk6F2nNFCqd1Fl6yk5vxcfHD0YEcUNnC9SL
> yBRmzNKsCh0d6rFaeLDBvkVjPZ7HQkWoJ/JdBBCLRvpE+1CGKVEmj69wK+n5uZ/Z
> O46yGLxJwx62Vxdqno2D57R52VRx2c3ec5t5M2HUy6+K5W73BO0+hGKh

---

From: Mike <[email-masked]>
Date: Sat, 29 Mar 2008 09:39:23 -0700

> you've come across the parable of the 50-foot pole.

Sure, the attacker runs around the pole.  The problem with that story
is that the pole in question is not nearly 50 feet tall.  It could be
easily jumped over, perhaps after a few years of improvements to
athletic shoes.

And actually I do trust 1024-bit RSA keys.  But only for signatures
such as those used for DHE_RSA.  You really do need to have a unique
key for every transaction (or possibly limited to a very small number
of transactions), which is what DHE provides.

> 1024-bit RSA with 
> it's enough that no attacker to date has targeted the cryptography. All 
> hacking and cracking you hear about is done without any attempt at 
> cryptanalysis. Rather, it's done through poor database permissions, poor 
> input sanitizations or social engineering.

The existence of other flaws is not an excuse to get the cryptography
wrong.  At some point it will be easy to break 1024-bit keys, and
with the mountain of transactions piling up, ALL USING THE EXACT SAME
KEYS, an attacker can simply passively record network traffic, wait a
few years and then run RSACrack1024.exe.

The damage is already done, by the way, if anybody is recording such
network traffic.  There is no way to prevent them from recovering all
that data, names, passwords, account numbers, transaction details.
And if you think you can just change your password and stop making
transactions on an offending site, you're wrong; your password change
will be recorded along with the rest of it.

> along with AES-256 and HMAC-SHA-256, but I don't think you can point to 
> any attacks that this would stop. In particular, it wouldn't save this 
> schools records:
> http://xkcd.com/327/

Funny cartoon, but that is not a cryptography problem.

> successful protocol, then yes, it looks like government intervention is 
> the best way to push forward more secure cryptography. Even a 
> non-binding standard for e-commerce would more likely than not push 
> visual indications for the cryptography strength, but that's nothing the 
> IETF should standardize.

You can forget all that and just convince software developers to use
DHE_RSA or DHE_DSS (or the EC equivalents) in preference to RSA_* in
all TLS clients and servers (especially servers).  Even with 80-bit-
secure 1024-bit DH parameters, we'd be a lot better off.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 29 Mar 2008 09:57:33 -0700

At Sat, 29 Mar 2008 09:39:23 -0700,
> will be recorded along with the rest of it.

Mike,

1. The properties of static RSA versus ephemeral DH are very 
   well known.
2. The protocol supports ephemeral DH.
3. The major servers support ephemeral DH, as do many clients.
4. Servers can choose to offer ephemeral DH if they wish
   without in any way breaking operation for clients which
   do not use it.
5. Clients could, if they chose, refuse to do any cipher suite
   other than DH.
6. For a variety of reasons, principally performance, many
   servers have chosen not to offer DH and clients have chosen
   not to require it.

I realize that you happen to think that people have made the wrong
decision, but clearly other people have different opinions
about the relevant cost/benefit issues. TLS offers a set of
mechanisms that people can choose from to meet their needs,
and the document is quite clear about the security properties
of static RSA versus DH (see F.1.1.2). We've done our job.

You should of course feel free to write an advocacy piece somewhere
about how people really should use DHE, but that's not really
something appropriate for the TLS WG to take on.

-Ekr

---

From: Mike <[email-masked]>
Date: Sat, 29 Mar 2008 09:58:32 -0700

>> literature. I don't see any benefit in the TLS WG rehashing

I think you have been involved too long to know what is well-known
to a total beginner (me 2 years ago).  It wasn't until very recently
that I figured out that it would be perfectly fine for a CA with a
2000-bit keycertsign certificate to issue a 4000-bit keyencipherment
certificate.  Everything I've read indicates that key sizes from the
end entity up through the root need to be non-decreasing (of course
they should for all the CA's in the chain).

> For that matter, much of it is in "SSL and TLS: Designing and

I've just ordered a copy, using 1024-bit RSA_RC4_MD5 from Amazon.
(I hadn't bought it before since I had already implemented SSL and
TLS when I first came across it.)

Mike

---

From: Mike <[email-masked]>
Date: Sat, 29 Mar 2008 10:15:25 -0700

> 3. The major servers support ephemeral DH, as do many clients.

This is where you are wrong.  Here is a list of servers that will
not negotiate DHE_RSA with any of AES128, AES256, or DES3:

   www.bankofamerica.com
   www.wellsfargo.com
   www.citibank.com
   www.americanexpress.com
   www.visa.com
   www.mastercard.com
   www.discovercard.com
   www.amazon.com
   www.apple.com
   www.microsoft.com
   www.ibm.com
   www.verisign.com
   www.godaddy.com
   www.equifax.com

There are only a few that I just tried that do:

   www.paypal.com
   www.entrust.com
   www.thawte.com

> something appropriate for the TLS WG to take on.

Ok, I guess that is what I will have to do.  I disagree that the
TLS WG can just write a spec and then they're done.  Any company
with a complex product (and the spec is a product of sorts) writes
whitepapers, and even sends experts to customer sites to make sure
it is installed properly.  Clearly we can't do the latter, but a
whitepaper is certainly doable (and needed!).

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 29 Mar 2008 10:24:41 -0700

At Sat, 29 Mar 2008 10:15:25 -0700,
> not negotiate DHE_RSA with any of AES128, AES256, or DES3:

I'm talking about the implementations, not the server operators. 
The server operators have chosen not to turn it on.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 29 Mar 2008 10:28:29 -0700

>something appropriate for the TLS WG to take on.

Exactly right. Such a document is quite reasonable for independent 
submission as an Informational RFC. If you write such a document, 
definitely tell the TLS WG about the various drafts so people can 
review it, but there is no need for it to be a WG-based document.

--Paul Hoffman, Director
--VPN Consortium

---

From: Mike <[email-masked]>
Date: Sat, 29 Mar 2008 10:31:10 -0700

> The server operators have chosen not to turn it on.

And that is precisely why they need a document telling them just
how damaging that choice is.  Which do you think will get more
attention, a whitepaper outlining the dangers of not using DHE
preferentially, written by some random guy named Mike, or the
same paper with the backing of the TLS WG of the IETF Internet
Security area?

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 29 Mar 2008 10:40:54 -0700

At Sat, 29 Mar 2008 10:31:10 -0700,
> same paper with the backing of the TLS WG of the IETF Internet

But the document *does* tell them exactly how damaging the choice
is. It says (S F.1.1.2.):

   With RSA, key exchange and server authentication are combined. The
   public key is contained in the server's certificate.  Note that
   compromise of the server's static RSA key results in a loss of
   confidentiality for all sessions protected under that static key. TLS
   users desiring Perfect Forward Secrecy should use DHE cipher suites.
   The damage done by exposure of a private key can be limited by
   changing one's private key (and certificate) frequently.

You seem to want us to go beyond that to tell them that they should
not use these modes, but that's not our job. 

-Ekr

---

From: Yoav Nir <[email-masked]>
Date: Sat, 29 Mar 2008 22:11:11 +0300

> same paper with the backing of the TLS WG of the IETF Internet

I think most vendors can't tell the difference between an  
Informational RFC and a standards-track RFC, and they definitely can't  
tell the difference between some guy named Mike and some guy named  
Eric from "RTMF Inc." This is meaningful for people who regularly read  
IETF mailing lists or attend the meetings.

You may want to find some co-author. Two authors from difference  
organizations give an RFC more prestige, especially if one is from a  
university. Of course if you could get Bruce himself..., but I get a  
feeling he doesn't like standards bodies very much.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Mike <[email-masked]>
Date: Sat, 29 Mar 2008 15:44:47 -0700

> but I know that others on this list are expert enough.

I think I should go with my own statement, and leave it to
anybody else who's interested in writing the document.  If
nobody is....

Mike

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 01 Apr 2008 01:07:49 +1300

Mike <[email-masked]> writes:

>What will it take to affect a change in this state of affairs that treats
>1024-bit keys as secure?

There are so many things that need to be fixed before 1Kbit keys even come
onto the radar that this isn't even an issue.  For example the entire multi-
billion(?) dollar phishing industry isn't going to go away even if we all
switch to 16Kbit keys overnight.  So you need to rephrase the question as:

  What will the effect be of a change to the state of affairs that treats
  1024-bit keys as secure?

Answer: None.

Peter.