IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 & draft-ietf-curdle-ssh-kex-sha2
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
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".
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 <kivinen%iki.fi@localhost> 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
--
kivinen%iki.fi@localhost
_______________________________________________
Curdle mailing list
Curdle%ietf.org@localhost
https://www.ietf.org/mailman/listinfo/curdle
Home |
Main Index |
Thread Index |
Old Index