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

["denis bider \(Bitvise\)" <[e-mail]>]

> As RFC 5647 was informational rather than standard track
> and does not play well with SSH negotiation of Cipher+MAC,
> I am not sure how to count it.

Yeah. :( These algorithms (AEAD_AES_128_GCM and AEAD_AES_256_GCM) really 
ought to be considered SHOULD NOT. The real SHOULD versions are 
[e-mail] and [e-mail], which currently do not 
have a formal spec, but are defined as "what RFC 5647 says, but with 
reasonable rules for algorithm negotiation".

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.


> 3) Public Key Algorithm Names
> Public Key Algorithm Name     Reference     Note
> ssh-dss        [RFC4253]    Section 6.6
> ssh-rsa        [RFC4253]    Section 6.6

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).

denis


----- Original Message -----
From: Mark D. Baushke
Sent: Monday, September 12, 2016 12:15
To: Tero Kivinen
Cc: Curdle ; IETF SSH
Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 & 
draft-ietf-curdle-ssh-kex-sha2

Tero Kivinen <[e-mail]> writes:

> That looks mostly ok. Most of the sha1 -> SHOULD NOT, with exception
> to the diffie-hellman-group14-sha1 and gss-group-14-sha1-*, which are
> still kept as SHOULD for backwards compatible reasons.

Yes.

> The MUSTs are good, but there seems to be quite a lot of SHOULD
> versions. Is there really need for that many SHOULD algoritms. For
> example is there reason to keep ecdh-sha2-* as SHOULD when
> curve25519-sha256 will be MUST?

I will move ecdh-sha2-* to MAY. The RFC5656 Section 4 said that every
SSH ECC implementation MUST implement ECDH key exchange. So, I was
transitioning all of those MUST to SHOULD requirements.

It is not clear to me if the curve25519 and curve448 KEX method
would fall into the RFC 5656 MUST requirements or not.

> Also, is there need to update other algorithms, i.e. encryption
> algorithms, MAC algorithms, Public key names, comperssion algorithms
> etc? Are the implementation requirements for them up to date (I do not
> know, as I have no idea which of them are now mandatory to implement,
> and which are not).

Good question. I am not sure if they are all being managed by the Curdle
Group or not.... I am not sure that they all belong in one document or
not. It seems like it might be better for each section to have its own
document specifying the MUST/SHOULD/MAY/SHOULD NOT advise...

The current IANA SSH Parameters are provided in:
  http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml

1) Encryption algorithms

We have a new one comding in Curdle:
  https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-chacha20-poly1305/
  but I do not see any drafts for SSH yet.

I suspect that one or more of these encryption ciphers should be avoided
(des-cbc and the arcfour* algorithms). I am not sure of the state of all
of them.

The SSH Encryption Algorithm Name list has the following IANA table:

Encryption Algorithm Name       Reference       Note
3des-cbc                        [RFC4253]       Section 6.3
blowfish-cbc                    [RFC4253]       Section 6.3
twofish256-cbc                  [RFC4253]       Section 6.3
twofish-cbc                     [RFC4253]       Section 6.3
twofish192-cbc                  [RFC4253]       Section 6.3
twofish128-cbc                  [RFC4253]       Section 6.3
aes256-cbc                      [RFC4253]       Section 6.3
aes192-cbc                      [RFC4253]       Section 6.3
aes128-cbc                      [RFC4253]       Section 6.3
serpent256-cbc                  [RFC4253]       Section 6.3
serpent192-cbc                  [RFC4253]       Section 6.3
serpent128-cbc                  [RFC4253]       Section 6.3
arcfour                         [RFC4253]       Section 6.3
idea-cbc                        [RFC4253]       Section 6.3
cast128-cbc                     [RFC4253]       Section 6.3
none                            [RFC4253]       Section 6.3
des-cbc                         [FIPS-46-3]     HISTORIC, See page 4
arcfour128                      [RFC4345]
arcfour256                      [RFC4345]
aes128-ctr                      [RFC4344]
aes192-ctr                      [RFC4344]
aes256-ctr                      [RFC4344]
3des-ctr                        [RFC4344]
blowfish-ctr                    [RFC4344]
twofish128-ctr                  [RFC4344]
twofish192-ctr                  [RFC4344]
twofish256-ctr                  [RFC4344]
serpent128-ctr                  [RFC4344]
serpent192-ctr                  [RFC4344]
serpent256-ctr                  [RFC4344]
idea-ctr                        [RFC4344]
cast128-ctr                     [RFC4344]
AEAD_AES_128_GCM                [RFC5647]       Section 6.1
AEAD_AES_256_GCM                [RFC5647]       Section 6.2


2) MAC Algorithm Names has the following IANA table:

MAC Algorithm Name      Reference       Note
hmac-sha1               [RFC4253]       Section 6.4
hmac-sha1-96            [RFC4253]       Section 6.4
hmac-md5                [RFC4253]       Section 6.4
hmac-md5-96             [RFC4253]       Section 6.4
none                    [RFC4253]       Section 6.4
AEAD_AES_128_GCM        [RFC5647]       Section 6.1
AEAD_AES_256_GCM        [RFC5647]       Section 6.2
hmac-sha2-256           [RFC6668]       Section 2
hmac-sha2-512           [RFC6668]       Section 2

Of the above, I believe that hmac-sha1-96, hmac-md5-96, and hmac-md5 are
considered insecure by some parties. As RFC 5647 was informational
rather than standard track and does not play well with SSH negotiation
of Cipher+MAC, I am not sure how to count it. Unless someone wants to
play with SHA-3 (FIPS PUB 202), or revise RFC 5647, I do not see any
real changes needed.

3) Public Key Algorithm Names

Public Key Algorithm Name Reference Note
ssh-dss [RFC4253] Section 6.6
ssh-rsa [RFC4253] Section 6.6
spki-sign-rsa [RFC4253] Section 6.6
spki-sign-dss [RFC4253] Section 6.6
pgp-sign-rsa [RFC4253] Section 6.6
pgp-sign-dss [RFC4253] Section 6.6
null [RFC4462] Section 5
ecdsa-sha2-* [RFC5656]
x509v3-ssh-dss [RFC6187]
x509v3-ssh-rsa [RFC6187]
x509v3-rsa2048-sha256 [RFC6187]
x509v3-ecdsa-sha2-* [RFC6187]




4) Compression Algorithms

> --
> [e-mail]

_______________________________________________
Curdle mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/curdle