Re: DH group exchange (Re: SSH key algorithm updates)

["Mark D. Baushke" <mdb%juniper.net@localhost>]

Hi Niels,

Niels Möller <nisse%lysator.liu.se@localhost> writes:

> Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost> writes:
> 
> > Since the verification process for both 186 and Lim-Lee generated
> > values is identical, you can verify the keys either way. So the spec
> > would cover both NIST and non-NIST options at the same time,
> > depending on implementer preference.
> 
> I'm not following the fine details here, but does the verification
> step include proving the primality of p (and q)?

There are two validations in FIPS 186-4:
a) Section A.1.1 Generation and Validation of Probable Primes
b) Section A.2.2 Assurance of the Validity of the Generator g

A FIPS implementation of ephemeral Finite Field Cryptography is expected
to generate p,q,g parameters using FIPS 186-4 methods.

There are two validations in NIST SP 800-56A:
a) Section 5.6.1.1 FFC Key Pair Generation
b) Section 5.6.2.4 FFC Full Public Key Validation Routine

A FIPS implementation of Diffie-Hellman is expected to generate a Key
Pair and do parameter validation using NIST SP 800-56A methods.

Right now, an implementation of RFC 4419 may assume a Sophie Germain
prime q with safe prime p such that p = 2q + 1. RFC 4419 section 6.1
Selection of Generator will often lead to values which are outside of
the q-ordered subgroup. Obviously, systems not using the Sophie Germain
and safe primes assumption does not have a q value on which to perform
validation, so from a FIPS point of view the key exchange would fail.

Niels Möller <nisse%lysator.liu.se@localhost> writes:

> "Mark D. Baushke" <mdb%juniper.net@localhost> writes:
> 
> > I would therefore really like to see it possible to express all of the
> > MODP groups via this new extension if possible.
> 
> I still think it is inappropriate to use group-exchange for groups
> that are going to be widely used. 

I suppose we disagree on this subject.

I believe it to be desirable to make published groups available to the
RFC 4419 extension mechanism when there may not have been time or
sufficient entropy to generate key pairs of the selected size for
ephemeral groups.

> Widely used groups should be subject to negotiation. 

I have no objection to this approach.

As has been noted by Peter, there are many different mechanisms for
generation of the primes to be used for ephemeral groups. It should be
possible to perform FIPS validation on those p,q,g parameters, but to do
that would require an extension to the possible messages to send q to
the client from the server.

As to your suggestion, I have no objection if we also want to add
negotiaion for some more fixed DH MODP groups.

It may also be desirable to setup a way that RFC 3526 groups:

  diffie-hellman-group14-sha256 (2048-bit MODP group - 112 bits of security)
  diffie-hellman-group15-sha256 (3072-bit MODP group - 128 bits of security)

  diffie-hellman-group16-sha384 (4096-bit MODP group - ~150 bits of security)

or

  diffie-hellman-group16-sha512 (4096-bit MODP group - ~150 bits of security)

could be used.

I do not really see a strong need for these:

  group17 (6144-bit MODP Group - ~170 bits of security)
  group18 (8192-bit MODP Group - ~190 bits of security)

at the present time.

> Group-exchange should be used only for ephemeral groups which each
> server discard before they get "widely used".

This is not a bad idea, but right now there exists only the ecdh-sha2-*
KEX which are FIPS compliant. Not all implementations of SSH seem to
want or are able to use ECDH. It is somewhat desirable to have a DH
mechanism that is able to use sha256 which leaves only
diffie-hellman-group-exchange-sha256 at present.

As has been noted, diffie-hellman-group-exchange-sha256 may be difficult
to use in a FIPS compliant manner as many implementations are not
selection a g that allows a FIPS compliant implementation to always
interoperate between client and server.

	Thanks,
	-- Mark