[Cryptography] Other obvious issues being ignored?

[Peter Gutmann]

Some other issues to take into account when trying to replace the parameters:

- Support for DH in MSIE was really poor for a long time, you needed a 1024-
  bit DSA server cert for it to work, and the only keys supported were in the
  range 512-1024 bits.

- Sun/Oracle (Java), ugh, also limited to 512-1024 bits for most of the
  lifetime of Java, finally fixed in Java 8 just short of the twenty year
  anniversary of the JDK.

- Because TLS sends the PKCS #3 form of the DH keys rather than the FIPS 186
  form, you can't verify the parameters you're being sent.  Using the RFC
  2409/3526 values makes parameter validation (via a memcmp()) functional, if
  not exactly elegant.  When you generate your own parameters, you're breaking
  the ability of the other side to verify your DH params.

- If you're worried about faults (embedded devices in harsh environments) then
  loading a fixed, pre-generated DH value from checksummed/ECC'd flash memory
  is safe, going through a lengthy keygen process with ephemeral data can be
  risky if there's a fault during the keygen process.

So it's not just a case of "scrap it and order a new one", you'd need to:

- Update TLS to allow transmission of the FIPS 186 form of the parameters
  (this is actually pretty trivial, you just need a signalling handshake
  extension in which the client indicates its readiness to accept the FIPS 186
  form), however getting it past the TLS WG could be nearly insurmountable.

- Figure out what the rollback implications are for the above.

- Figure out whether you want to risk keygen fault issues.

- Figure out how many clients will break when you move to keys over 1024 bits
  (if you're generating your own DH values then this is mitigated somewhat by
  staying with 1024 and doing a regen from time to time, even if the NSAs can
  break 1024-bit keys they probably won't expend the effort on a key that's
  only valid for a few hours).

Peter.