Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 & draft-ietf-curdle-ssh-kex-sha2

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

denis bider (Bitvise) <ietf-ssh3%denisbider.com@localhost> writes:

> Yeah. :( These algorithms (AEAD_AES_128_GCM and AEAD_AES_256_GCM)
> really ought to be considered SHOULD NOT. The real SHOULD versions are
> aes128-gcm%openssh.com@localhost and aes256-gcm%openssh.com@localhost, which currently do
> not have a formal spec, but are defined as "what RFC 5647 says, but
> with reasonable rules for algorithm negotiation".

I admit I like the OpenSSH specification better myself.

> We ought to make this formal by specifying new algorithm names
> aes128-gcm and aes256-gcm, and defining this in roughly the same way
> (what RFC 5647 says, but with reasonable negotiation rules). It should
> be identical to the @openssh.com versions, except with formally
> adopted names.
> 
> If we want to do this, I can write up this spec.

I think the only reason I have seen folks list AEAD_AES_nnn_GCM in
requirements documents is to appease the either Common Criteria or FIPS
standards.

Things got odd when the NIST SP 800-38D references were put into the
FIPS 140-2 Implementation Guidance in section A.5 in March 2009. It
changed last year, but it is still not entirely clear how this section
impacts SSH. The section provides techniques for generation an IV that
are acceptable for the purpose of FIPS 140-2 validations, but only list
TLS-v1.2 and IPsec-v3.

Folks who want to read the current details can look in
http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf
Section A.5 was last modified on August 7, 2015.

The NIST SP 800-38D should be found at this URL:
http://dx.doi.org/10.6028/NIST.SP.800-38D

(it redirects to
http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38D.pdf).
The 8.2.1 Deterministic Construction alternative seems to be the only
one that still meets the FIPS 140-2 guidance.

> > 3) Public Key Algorithm Names
> This table should be expanded with another column, Signature Algorithm
> Name. For most algorithms, it's just a copy of the value in Public Key
> Algorithm Name. For ssh-rsa, however, there need to be two additional
> lines, for three total:
> 
> ssh-rsa   ssh-rsa        [RFC4253]       Section 6.6
> ssh-rsa   rsa-sha2-256   (other draft)   Section 2
> ssh-rsa   rsa-sha2-512   (other draft)   Section 2
> 
> The "other draft" in this case is the rsa-sha2 draft.
> 
> I should modify that draft to update this table in this way. The
> current version of the draft does not suggest adding the extra column,
> but instead adds the new signature algorithm names in the existing
> Public Key Algorithm Name column, which is not fully correct (and may
> mislead implementers).

That sounds like a good plan to me.

	-- Mark