Re: [Curdle] AD Review of draft-ietf-curdle-gss-keyex-sha2-05

[Mark Baushke <[e-mail]>]

> On Apr 7, 2018, at 8:10 AM, Russ Housley <[e-mail]> wrote:
> 
> Denis:
> 
>> I'm not an author of this draft, but I can respond with respect to the following:
>> 
>> > > | gss-group14-sha256-*     | SHOULD/RECOMMENDED
>> > > | gss-group15-sha512-*     | MAY/OPTIONAL
>> > > | gss-group16-sha512-*     | SHOULD/RECOMMENDED
>> >
>> > Why are you only specifying SHA-512 with 4096-bit groups.
>> > SHA-256 is still reasonable at that size?
>> 
>> There exist NSA recommendations aimed at "organizations that run classified or unclassified national security systems (NSS) and vendors that build products used in NSS."
>> 
>> https://cryptome.org/2016/01/CNSA-Suite-and-Quantum-Computing-FAQ.pdf
>> 
>> These recommendations cover a usage case for software that implements the above algorithms. These recommendations call for the following minimums:
>> 
>> - Diffie Hellman: 3072-bit or larger
>> 
>> - Hashing: SHA-384 or larger
>> 
>> These recommendations are most effectively met by associating group15 and group16 with SHA-512.
>> 
>> Otherwise, products that wanted to meet these recommendations would have to use much larger and more expensive DH groups in order to meet the SHA-384-or-better requirement.
> 
> I do not quite understand this response.  I can understand a desire to include a ciphersuite that aligns with the NSA guidance so that anyone that needs to follow it can easily do so, but that does not seem to be what you are suggesting.  Looking at page 2 of the document that you cite, a ciphersuite that uses the NIST P-384 curve, SHA-384, and AES-256 is needed.

The key exchange ECDH NISTP-384 with SHA-384 is already in RFC 5656 along with ECDSA NISTP-384 with SHA-384 as a public key algorithm.

AES256-CBC is OPTIONAL in RFC4250 and RFC4253 as a symmectric cipher.

AES256-CTR is RECOMMENDED in RFC4344 as a symmectric cipher.

RFC3526 groups are provided for SSH in RFC8268:

group14 with sha256 is SHOULD/RECOMMENDED in RFC8268

group15 with sha512 is OPTIONAL in RFC8268

group16 with sha512 is OPTIONAL in RFC8268

group17 with sha512 is OPTIONAL in RFC8268

group18 with sha512 is OPTIONAL in RFC8268

Should we have decomposed the group with the hash? Or, should we have used shorter key exchange algorithm names? 
Well, perhaps both would have been better, but that should have been done some years ago.

The negotation list is getting a bit long these days and the SSH implementors did not seem to fancy adding SHA256, SHA384, and SHA512 variations of each of the new diffie-hellman groups being added, so the longest one (SHA512) was chosen as it slightly faster to implement on 64-bit architecture machines.

I am given to understand that NIST SP 800-56A revision 3 and FIPS PUB 186-5 may address the use of Finite Field Cryptography safe primes for Diffie-Hellman key exchange sometime this year. (see also URL:
https://csrc.nist.gov/CSRC/media/Publications/sp/800-56a/rev-3/draft/documents/sp800-56ar3-draft.pdf
section 5.5.1 and Appendix E which allow RFC3526 and RFC7919 groups)

For myself, I tend to think that using 2048-bit prime P FFC Diffie-Hellman provable primes that are generated on a bi-weekly basis with Q as a large subgroup of approximately P/2 bits in length and G is a proper generator of q-ordered subgroups. If changed often enough, then there would be no big push to try to precalcualte the majority of the factors of such parameters. Even if we have sufficient sieves to help in factorization, there is still a lot of computation behind breaking a large subgroup. In a Post-Quantum Cryptography world, I tend to trust large FFC calculations over small ECC calculations. Although something better than either would be welcome... always allowing it is desirable to still be able to connect to small embedded devices too.

With RFC4419 and RFC8270 we get safe primes generated with P being a 2048-bits or larger prime. The only downside is that the example calcuation does not always choose a generator g which generates a q-ordered subgroup.

> 
> I would be in favor os adding such a ciphersuite as MAY/OPTIONAL.

I think this may already be present, depending on what you are asking.

For myself, I see no problems with the GSS variations of diffie-hellman using the same groups and hashes as RFC8268.
For gss-group14-sha256-* I support RECOMMENDED to move away from the SHA1 variation. I am okay with
gss-group16-sha512-* as either OPTIONAL or RECOMMENDED.

        -- Mark