[Bug 1002434] Re: TLS interoperability issue in NSS based software

[Bug Watch Updater]

Launchpad has imported 3 comments from the remote bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=636802.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2011-02-25T19:46:42+00:00 Bsmith-mozilla wrote:

See blapit.h:

#define DH_MAX_P_BITS         2236

I would expect some servers to want to use 3072-bit keys (to match
AES-128) based on the NIST guidelines. I did not find any such limit in
OpenSSL (though I looked only briefly).

Reply at: https://bugs.launchpad.net/nss/+bug/1002434/comments/0

------------------------------------------------------------------------
On 2011-02-26T05:59:12+00:00 Nelson-bolyard wrote:

IIRC, that number was chosen after measuring execution time for various 
large primes and then choosing an upper bound on the acceptable amount of 
time, above which the operation would be considered a denial of service.

Numbers which are set in that way need to be better documented with respect 
to the criteria by which they were chosen, and then revisited from time to 
time to update them, provided that the criteria are still valid.

Reply at: https://bugs.launchpad.net/nss/+bug/1002434/comments/1

------------------------------------------------------------------------
On 2012-05-21T17:11:52+00:00 Janne Snabb wrote:

Yes, it is about time DH_MAX_P_BITS should be bumped.

Currently NSS has a serious emerging interoperability issue with GnuTLS:

GnuTLS 2.12.0 which was released a bit more than a year ago introduced a
new function "gnutls_sec_param_to_pk_bits()" which offloads the burden
of selecting suitable key sizes from individual software authors to
GnuTLS library maintainers. See the following URL for more information
on this:

https://www.gnu.org/software/gnutls/manual/html_node/Selecting-
cryptographic-key-sizes.html

As can be seen, GnuTLS now suggests 2432 bits DHE key size on "NORMAL"
security level and 3248 bits on "HIGH" security level. Neither of these
settings can inter-operate with NSS with the current maximum key size of
2236 bits. Only security levels "LOW" and "LEGACY" can inter-operate
with NSS.

The only reason people are not hitting this frequently right now is that
this GnuTLS API call is new and not much of the mainstream software uses
it yet (because they want to be compatible with the older API). Most
software still uses hard-coded 1024 or 2048 key size.

Exim's (a very popular MTA) GnuTLS support was revamped just now, and as
a result Thunderbird was not able to do STARTTLS any more. The Exim code
had to be patched to clamp down the maximum key size to 2236 bits so
that it can still interoperate with NSS based software. Such hacks are
ugly and should not be needed.

The last time this maximum key size was increased is documented at the
following bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=259229

That was about 7.5 years ago. Any measured execution times 7.5 years ago
are completely irrelevant today.

I propose bumping DH_MAX_P_BITS preferably to 8k or at the very least to
4k to allow interoperability for the next couple of years. The best
would be to have a mechanism which allows NSS consumers to configure
this.

Best Regards,
Janne Snabb

Reply at: https://bugs.launchpad.net/nss/+bug/1002434/comments/2


** Changed in: nss
       Status: Unknown => Confirmed

** Changed in: thunderbird
       Status: Unknown => Confirmed

** Changed in: nss
   Importance: Unknown => Low

** Changed in: thunderbird
   Importance: Unknown => Low

** Bug watch added: Mozilla Bugzilla #259229
   https://bugzilla.mozilla.org/show_bug.cgi?id=259229

-- 
You received this bug notification because you are a member of Mozilla
Bugs, which is subscribed to nss in Ubuntu.
https://bugs.launchpad.net/bugs/1002434

Title:
  TLS interoperability issue in NSS based software

To manage notifications about this bug go to:
https://bugs.launchpad.net/nss/+bug/1002434/+subscriptions