Gather data about possible transition to 2048bit RSA/DHE

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: 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.

changed milestone to %Tor: 0.2.6.x-final in legacy/trac

added 026-triaged-1 in Legacy / Trac component::core tor/tor in Legacy / Trac milestone::Tor: 0.2.6.x-final in Legacy / Trac needs-analysis in Legacy / Trac needs-proposal in Legacy / Trac owner::ioerror in Legacy / Trac priority::medium in Legacy / Trac resolution::implemented in Legacy / Trac status::closed in Legacy / Trac tor-relay in Legacy / Trac type::enhancement in Legacy / Trac version::tor unspecified in Legacy / Trac labels

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.

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

Trac:
Milestone: Tor: 0.2.3.x-final to Tor: unspecified

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

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!

The raw data is now published: https://www.ssllabs.com/ext/pulse/README.FIRST https://www.ssllabs.com/ext/pulse/

Trac:
Keywords: N/A deleted, tor-relay added

Trac:
Component: Tor Relay to Tor

Should close this ticket since we went with EC?

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.

Trac:
Keywords: tor-relay deleted, tor-relay needs-analysis needs-proposal added
Milestone: Tor: unspecified to Tor: 0.2.5.x-final

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?

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.

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.

Trac:
Milestone: Tor: 0.2.5.x-final to Tor: 0.2.6.x-final

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.

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.

Trac:
Keywords: tor-relay needs-analysis needs-proposal deleted, tor-relay needs-analysis needs-proposal 026-triaged-1 added

Closing this as done. The investigation is investigated. Opening legacy/trac#13752 (moved) for the implementation.

Trac:
Resolution: N/A to implemented
Status: new to closed

closed

mentioned in issue legacy/trac#6089 (moved)

mentioned in issue legacy/trac#13752 (moved)

moved from legacy/trac#6088 (moved)

added Feature label and removed 1 deleted label

added Needs Proposal Relay labels and removed 1 deleted label