Opened 23 months ago

Last modified 6 weeks ago

#6088 new enhancement

Gather data about possible transition to 2048bit RSA/DHE

Reported by: ioerror Owned by: ioerror
Priority: normal Milestone: Tor: 0.2.6.x-final
Component: Tor Version: Tor: unspecified
Keywords: tor-relay needs-analysis needs-proposal Cc:
Actual Points: Parent ID:
Points:

Description

I propose that while prop 198 and others cover some crypto changes we need to make - I think they won't be made quickly enough. I think that we should jump to 2048bit rsa and 2048bit DHE as soon as possible. We should do this before 0.2.4.x (which nick says will enable TLS-ECDHE by default) as we have a long way before 0.2.4.x is even remotely available.

The first thing is that nick says:
<nickm> I want to know performance impact and fingerprintability.

This ticket should gather data on performance (RSA/DHE/etc) for servers and on the issue of fingerprintability (mitm filter/block/etc) where people use 2048bit DHE.

I've put this as a 02.3.x-final Milestone but it's likely this will change.

Child Tickets

Change History (14)

comment:1 Changed 23 months ago by ioerror

According to https://www.ssllabs.com/ssltest/ - we see a few trends with SSL/TLS servers - one of the most important ones is that 2048bit RSA is becoming more common.

Their SSLPulse setup shows a lot of this:
https://community.qualys.com/blogs/securitylabs/2012/04/27/announcing-ssl-pulse

Here's the site:
https://www.trustworthyinternet.org/ssl-pulse/

From their data - around 80% of sites use 2048bit RSA. I'm going to ask them directly about DHE as it appears to be missing from their monthly summary.

comment:2 Changed 23 months ago by nickm

I'd also like to know, if they have the data, what fraction of DHE users are using the mod_ssl prime.

comment:3 Changed 23 months ago by nickm

  • Milestone changed from Tor: 0.2.3.x-final to Tor: unspecified

comment:4 Changed 23 months ago by ioerror

I've emailed Ivan - we'll see if he has the answers to our questions...

comment:5 Changed 23 months ago by ioerror

Ivan wrote back and he says:

I may have the data already; have a look at the samples below. Each of
these is the contents of a "suites" field. DH parameters are recorded
when offered by the server.

To calculate the strength, multiply DH_p by 8.

10080; 20080; 30080; 40080; 60040; 700c0; 80080; 3; 4; 5; 6; 8; 9; a; 14
(DH_p 64, DH_g 1, DH_Ys 64); 15 (DH_p 128, DH_g 1, DH_Ys 128); 16 (DH_p
128, DH_g 1, DH_Ys 128); 2f; 33 (DH_p 128, DH_g 1, DH_Ys 128); 35; 39
(DH_p 128, DH_g 1, DH_Ys 128);

 a; 16 (DH_p 128, DH_g 1, DH_Ys 128); 2f; 33 (DH_p 128, DH_g 1, DH_Ys
128); 35; 39 (DH_p 128, DH_g 1, DH_Ys 128); 41; 45 (DH_p 128, DH_g 1,
DH_Ys 128); 84; 88 (DH_p 128, DH_g 1, DH_Ys 128);

 4; 5; a; 16 (DH_p 128, DH_g 1, DH_Ys 128); 2f; 33 (DH_p 128, DH_g 1,
DH_Ys 128); 35; 39 (DH_p 128, DH_g 1, DH_Ys 128);

 a; 16 (DH_p 128, DH_g 1, DH_Ys 128); 2f; 33 (DH_p 128, DH_g 1, DH_Ys
128); 35; 39 (DH_p 128, DH_g 1, DH_Ys 128);

 a; 16 (DH_p 128, DH_g 1, DH_Ys 128); 2f; 33 (DH_p 128, DH_g 1, DH_Ys
128); 35; 39 (DH_p 128, DH_g 1, DH_Ys 128);

 a; 16 (DH_p 128, DH_g 1, DH_Ys 128); 2f; 33 (DH_p 128, DH_g 1, DH_Ys
128); 35; 39 (DH_p 128, DH_g 1, DH_Ys 128);

 4; 5; a; 16 (DH_p 128, DH_g 1, DH_Ys 128); 2f; 33 (DH_p 128, DH_g 1,
DH_Ys 128); 35; 39 (DH_p 128, DH_g 1, DH_Ys 128);

Here are some crude stats:

- There are 215,607 in my database
- 118,641 hostnames support DH in some form
- 311 have DH_p of 256.

...

So the number may be 314 


I plan to release my raw data to everyone next week.

So we're good with RSA 2048bit but we're not so good with the thing that REALLY matters which is 2048bit DH. :( Shit luck!

comment:7 Changed 19 months ago by nickm

  • Keywords tor-relay added

comment:8 Changed 19 months ago by nickm

  • Component changed from Tor Relay to Tor

comment:9 Changed 7 months ago by arma

Should close this ticket since we went with EC?

comment:10 Changed 7 months ago by nickm

  • Keywords needs-analysis needs-proposal added
  • Milestone changed from Tor: unspecified to Tor: 0.2.5.x-final

Not necessarily; we're using EC for ECDHE in our handhakes, but still using RSA for identity in our handshakes.

If we can move our handshakes to use RSA1024, that would be swell.

I need to re-analyze the v3 handshake protocol, though, to double-check whether the outermost RSA key even matters.

comment:11 Changed 6 weeks ago by andrea

Triage for 0.2.5.x: this sounds like it's still a bit open-ended for this late in 0.2.5.x; punt to 0.2.6?

comment:12 Changed 6 weeks ago by andrea

Also, if we're going to mess with the old handshake, should we consider making the size negotiable between the nodes rather than changing to another fixed value? Should we consider supporting multiple handshakes and hashing together to generate a shared secret for the sake of not putting all eggs in one basket? I think we (myself and nickm) briefly touched on that at the Reykjavik meeting.

comment:13 follow-up: Changed 6 weeks ago by nickm

  • Milestone changed from Tor: 0.2.5.x-final to Tor: 0.2.6.x-final

Fine punting to 0.2.6. (The backport will be that it either works or it doesn't.)

AFAICT, it doesn't do us any good to make the RSA link certificates longer unless we do it as part of some kind of effort like prop220.

Argument: Since we're using an adequate EC group for our ECDHE, we get forward secrecy except against an active MITM. But any MITM that's enabled by RSA1024 would work just as well if we increased the link key size to 2048 bits, since the identity key size is still RSA1024 until we implement proposal 220.

comment:14 in reply to: ↑ 13 Changed 6 weeks ago by andrea

Replying to nickm:

Fine punting to 0.2.6. (The backport will be that it either works or it doesn't.)

AFAICT, it doesn't do us any good to make the RSA link certificates longer unless we do it as part of some kind of effort like prop220.

Argument: Since we're using an adequate EC group for our ECDHE, we get forward secrecy except against an active MITM. But any MITM that's enabled by RSA1024 would work just as well if we increased the link key size to 2048 bits, since the identity key size is still RSA1024 until we implement proposal 220.

Agree with that argument and fine with punting to 0.2.6 then.

Note: See TracTickets for help on using tickets.