feature request: more DH prime size edge cases

[roycewilliams]

As a way to verify client restrictions that do not allow less than 1024 bits.

[roycewilliams]

The closest I've seen in the wild is 768-bit, but the closer to 1023, the better.

[lgarron]

Adding ore DH parameter sizes should be easy.

What kinds of clients would use these restrictions? Are there other common common restrictions you might want to test? In particular, is there a use for 2047-bit? 1025-bit?

[roycewilliams]

Fair question. Here are relevant references: announcement for Firefox, issue for Chrome, announcement for IE, announcement for OpenSSL.

The advice at weakdh.org summarizes it well:

Make sure any TLS libraries you use are up-to-date, that servers you maintain use 2048-bit or larger primes, and that clients you maintain reject Diffie-Hellman primes smaller than 1024-bit.

... and:

We further estimate that an academic team can break a 768-bit prime and that a nation-state can break a 1024-bit prime.

Clients have been enforcing values as close to, but not exactly equal to, well-known sizes (512, 768, 1024, 2048). I do not know what possible values are on all platforms, but it would be useful to check as closely on either side of these as possible.

It's also a moving target. The clients have been raising the bar incrementally as time goes on. OpenSSL started with blocking 768 immediately, and then 1024 later. And capabilities change over time - blocking less than 2048 was not feasible when Logjam was announced, because there were simply too many sites that would be affected. But that day may come soon, such that implementers are aiming for that threshold as well. And even though 512 and 768 have been deprecated for some time, there are likely still legacy platforms that need to test for them as part of migration planning.

Since badssl.com is intended to be a full test suite, I would suggest the highest possible values that are closest to 511, 767, 1023, (maybe 1535?), and 2047.

[lgarron]

The advice at weakdh.org summarizes it well:

Make sure any TLS libraries you use are up-to-date, that servers you maintain use 2048-bit or larger primes, and that clients you maintain reject Diffie-Hellman primes smaller than 1024-bit.

I think that's a pretty good case for dh1023.

... except that Java apparently requires multiples of 64. 😢😢😢

http://stackoverflow.com/questions/36298394/java-invalidalgorithmparameterexception-prime-size-must-be-multiple-of-64

Perhaps it's worth having dh1023 for divisibility intolerance, and dh960 for size intolerance?
But can we rely on a client to give a useful error message for dh960 if it expects, say, multiples of 128? Should we use dh1025 to test divisibility intolerance instead?

I'm now wondering if it would be too crazy to support all dh**** values up to, say, 4096.

• Generating a lot of constants would be very computation-intensive but far from impossible.
• dh2048.pem is only 424 bytes, so a set of 4096 constants would only be a few megabytes.
• nginx support regex matching for server_name.
  However, that makes it cumbersome to enumerate all hosts, which we need for e.g. /etc/hosts (via make list-hosts).

Maybe powers of two, each at {-64, 0, +64}, is sufficiently interoperable but pragmatic.

Thoughts on 1023 vs. 960?

[roycewilliams]

Ah, good catch!

I personally like the idea of {-64, -1, 0, +1, +64}. This supports the entire set of corner cases that most of the user base could conceivably need (and might even reveal previously undetected client implementation issues). But I'm often accused of undue diligence. :)

I assume that the enumeration of all hosts would be a one-time event (development-wise), and would be relatively easy to script?

Not knowing any better, if the interoperability issues are wholly client-side Java in nature, could the non-Java-compatible hosts be visually set off in some way? Color is already used for important good/bad signaling, but maybe an asterisk, italics, etc.? This wouldn't help users who are doing automated testing, but it would minimize manual testers' getting unhandled errors.

[roycewilliams]

And in anticipation of feature requests for other DH values, a future-ready solution to hosts enumeration would merge and dedupe two lists: a generated list of values, and a manually maintained list.

[april]

I assume that the enumeration of all hosts would be a one-time event (development-wise), and would be relatively easy to script?

One time and doable for {-64, -1, 0, +1, +64}. It would take approximately a billion years if we wanted to do it for all values between, say, 1 and 2^14+1.

[lgarron]

So, how's the following?

-dh448
-dh511
-dh512
-dh513
-dh576
-dh960
-dh1023
-dh1024
-dh1025
-dh1088
-dh1984
-dh2047
-dh2048
-dh2049
-dh2112

[roycewilliams]

Looks right to me -- all four values for 512, 1024, and 2048.

[april]

I wouldn't mind seeing 2^12, 2^13, 2^14, and maybe 2^15 and 2^16 (if they're even possible to generate). 10000-sans is my favorite domain already so of course this is to be expected. :)

[roycewilliams]

That would yield:

-dh448
-dh511
-dh512
-dh513
-dh576
-dh704
-dh767
-dh768
-dh769
-dh832
-dh960
-dh1023
-dh1024
-dh1025
-dh1088
-dh1984
-dh2047
-dh2048
-dh2049
-dh2112
-dh4032
-dh4095
-dh4096
-dh4097
-dh4160
-dh8128
-dh8191
-dh8192
-dh8193
-dh8256
-dh16320
-dh16383
-dh16384
-dh16385
-dh16448
-dh32704
-dh32767
-dh32768
-dh32769
-dh32832
-dh65472
-dh65535
-dh65536
-dh65537
-dh65600

[lgarron]

That seems like a little overkill; most client tolerance boundaries we care about are likely to be below 1024 (or at least below 2048).

I'd go for the ones in my previous comment, and then the higher powers of 2 on their own. Assuming @marumari wants to generate them, of course. :-P

[roycewilliams]

Works for me. :)