Opened 3 years ago

Closed 10 months ago

#6088 closed enhancement (implemented)

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 026-triaged-1 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 (16)

comment:1 Changed 3 years 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 3 years 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 3 years ago by nickm

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

comment:4 Changed 3 years ago by ioerror

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

comment:5 Changed 3 years 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 3 years ago by nickm

  • Keywords tor-relay added

comment:8 Changed 3 years ago by nickm

  • Component changed from Tor Relay to Tor

comment:9 Changed 23 months ago by arma

Should close this ticket since we went with EC?

comment:10 Changed 23 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 18 months 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 18 months 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 18 months 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 18 months 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.

comment:15 Changed 15 months ago by nickm

  • Keywords 026-triaged-1 added

I think all that is left here is switching from 1024-bit RSA link keys to 2048-bit RSA link keys.  According to some surveys, 2048-bit link keys are already in a majority for websites, so this won't be a huge deal.

P256 ECDHE is fairly common in the wild, but 2048-bit DHE is quite rare.

I did some quick experiments to tell whether changing to better certificates would break compatibility. It appears that 0.2.2 and later all work just fine with 2048-bit link keys.

It's possible, however, that we want to want to do more here. It's pretty unusual to have a 2048-bit certificate that's signed by a 1024-bit key. So when we send out our link certificate for TLS, we want to have a dummy 2048-bit key sign it -- and we want to present a real identity-key-signed link cert when we do our CERTS cells.

I've verified that doing *that* works just fine with 0.2.3 and later, and hacked up a chutney network to the point where it kinda just works with the v2 handshake. I think I have the v1 handshake working too, but I haven't tested it.

(I don't know whether we care very much about v2 and v1, or whether we're deprecating them... but at least, using 2048-bit link keys signed by 2048-bit temporary keys won't force us to deprecate them.)

My hacks are in a branch "ticket6088_hax". They need more work to get applied. There's not much point applying them without also doing proposal 220.

comment:16 Changed 10 months ago by nickm

  • Resolution set to implemented
  • Status changed from new to closed

Closing this as done. The investigation is investigated. Opening #13752 for the implementation.

Note: See TracTickets for help on using tickets.