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

From: Tero Kivinen <[email-masked]>
Date: Mon, 12 Sep 2016 16:08:58 +0300

Mark D. Baushke writes:
> Key Exchange Method Name              Reference     Note
> curve25519-sha256                     ssh-curves    MUST
> diffie-hellman-group-exchange-sha1    RFC4419       SHOULD NOT
> diffie-hellman-group1-sha1            RFC4253       SHOULD NOT
> diffie-hellman-group14-sha1           RFC4253       SHOULD
> diffie-hellman-group14-sha256         new-modp      MUST
> diffie-hellman-group16-sha512         new-modp      SHOULD
> ecdh-sha2-nistp256                    RFC5656       SHOULD
> ecdh-sha2-nistp384                    RFC5656       SHOULD
> ecdh-sha2-nistp521                    RFC5656       SHOULD
> gss-gex-sha1-*                        RFC4462       SHOULD NOT
> gss-group1-sha1-*                     RFC4462       SHOULD NOT
> gss-group14-sha1-*                    RFC4462       SHOULD
> gss-group14-sha256-*                  new-modp      SHOULD
> gss-group16-sha512-*                  new-modp      SHOULD
> rsa1024-sha1                          RFC4432       SHOULD NOT

(I remove algorithms with status of MAY, to make it shorter).

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.

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?

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). 
-- 
[email-masked]

---

From: "Mark D. Baushke" <[email-masked]>
Date: Mon, 12 Sep 2016 11:26:28 -0700

[Regretfully an incomplete draft of this escaped prematurely, pardon
the repetition. -- Mark]

> still kept as SHOULD for backwards compatible reasons.

Yes.

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

> know, as I have no idea which of them are now mandatory to implement,

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 algorithm in Curdle:
  https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-chacha20-poly1305/
but I do not see any drafts for SSH yet to use it yet. I would favor
seeing [email-masked] become chacha20-poly1305 if
someone wants to write a draft for it.

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

Changes in flight are:
https://datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2/

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]

The ssh-dss and ssh-rsa algorithms use SHA-1 and the ssh-dss for
values less than 2048-bits seems unlikely to be very secure today.

4) Compression Algorithms

I don't see a need to update these...

Compression Algorithm Name      Reference       Note
none                            [RFC4253]       Section 6.2
zlib                            [RFC4253]       Section 6.2

There are other SSH Parameters, I am not sure if any others need to be
deprecated at this time.

	-- Mark

---

From: "Mark D. Baushke" <[email-masked]>
Date: Mon, 12 Sep 2016 11:15:15 -0700

Yes.

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.

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.

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Mon, 12 Sep 2016 13:56:56 -0600

> 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 
[email-masked] and [email-masked], 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.

> 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

Yes.

1) Encryption algorithms

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

---

From: "Mark D. Baushke" <[email-masked]>
Date: Mon, 12 Sep 2016 13:57:20 -0700

denis bider (Bitvise) <[email-masked]> 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
> [email-masked] and [email-masked], 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.
> 

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.

> 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:
> 
> 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

---

From: "Mark D. Baushke" <[email-masked]>
Date: Sun, 11 Sep 2016 21:09:12 -0700

I have split out a new draft draft-ietf-curdle-ssh-modp-dh-sha2 [1]
(called "new-modp" in the Reference table below) forked from the
draft-ietf-curdle-ssh-kex-sha2-04 draft. It specifies the new MOD DH KEX
Groups that use SHA-2 hashes. This edition specifies both the new
diffie-hellman-group* names of the -04 revision as well as adding the
gss-group* names.

Before I update draft-ietf-curdle-ssh-kex-sha2-05 to point to it, I
would like to take a straw poll of which algorithms (if any) should be
defined as a MUST to implement. My personal preference was just
curve25519-sha256. However, at least a few implementors have said that
they were not planning to do any ECDH implementations. So, I am guessing
that "diffie-hellman-group14-sha256" may be the only one that everyone
might be able to agree is a MUST to implement.

Key Exchange Method Name              Reference     Note
curve25519-sha256                     ssh-curves    MUST
curve448-sha512                       ssh-curves    MAY
diffie-hellman-group-exchange-sha1    RFC4419       SHOULD NOT
diffie-hellman-group-exchange-sha256  RFC4419       MAY
diffie-hellman-group1-sha1            RFC4253       SHOULD NOT
diffie-hellman-group14-sha1           RFC4253       SHOULD
diffie-hellman-group14-sha256         new-modp      MUST
diffie-hellman-group15-sha512         new-modp      MAY
diffie-hellman-group16-sha512         new-modp      SHOULD
diffie-hellman-group17-sha512         new-modp      MAY
diffie-hellman-group18-sha512         new-modp      MAY
ecdh-sha2-nistp256                    RFC5656       SHOULD
ecdh-sha2-nistp384                    RFC5656       SHOULD
ecdh-sha2-nistp521                    RFC5656       SHOULD
ecdh-sha2-*                           RFC5656       MAY
ecmqv-sha2                            RFC5656       MAY
gss-gex-sha1-*                        RFC4462       SHOULD NOT
gss-group1-sha1-*                     RFC4462       SHOULD NOT
gss-group14-sha1-*                    RFC4462       SHOULD
gss-group14-sha256-*                  new-modp      SHOULD
gss-group15-sha512-*                  new-modp      MAY
gss-group16-sha512-*                  new-modp      SHOULD
gss-group17-sha512-*                  new-modp      MAY
gss-group18-sha512-*                  new-modp      MAY
gss-*                                 RFC4462       MAY
rsa1024-sha1                          RFC4432       SHOULD NOT
rsa2048-sha256                        RFC4432       MAY

I plan to post the above table in the new
draft-ietf-curdle-ssh-kex-sha2-05 draft
after 05:00 UTC on 12 September 2016.

Of course, everyone can still lobby for changes with the Curdle group, I
just don't want to generate a huge number of revisions if possible.

	Thank you,
	-- Mark

URL: [1] https://tools.ietf.org/html/draft-ietf-curdle-ssh-modp-dh-sha2-00

---

From: Damien Miller <[email-masked]>
Date: Wed, 14 Sep 2016 03:47:20 +1000 (AEST)

> ecdh-sha2-nistp521                    RFC5656       SHOULD

Has anyone ever implemented this? AFAIK the motivation for this was
MQV being included in NSA Suite B at the time, but it was subsequently
dropped. IMO if nobody is using it then it should be recommended
against. I.e. SHOULD NOT

> gss-group14-sha256-*                  new-modp      SHOULD

IMO these two should be MAY. Most implementations don't support
GSSAPI key exchange at all.

Thanks for your patience in wrangling this.

-d

---

From: "Mark D. Baushke" <[email-masked]>
Date: Tue, 13 Sep 2016 12:21:53 -0700

> dropped. IMO if nobody is using it then it should be recommended

Hmmm... ecmqv-sha2 is mentioned in defined in RFC 5656 and mentioned in
RFC 6187. I see a JIRA request to add it to MINA SSHD, but I am unaware of
any implementations of it. 

I have no problems moving ecmqv-sha2 to SHOULD NOT if no one has
implemented it. However, I guess I should ask that of the ietf-ssh list
first.

> GSSAPI key exchange at all.

Perhaps I need a paragraph like this one:

     If GSS-API methods are available, then the RFC4462 REQUIRED
     gss-group14-sha1-* method SHOULD be retained for compatibility
     with older Secure Shell implementations and the
     gss-groups14-sha256-* method SHOULD be added as for "sha1".

	-- Mark

---

From: Damien Miller <[email-masked]>
Date: Wed, 14 Sep 2016 05:32:17 +1000 (AEST)

>      gss-groups14-sha256-* method SHOULD be added as for "sha1".

Sounds good, and maybe with an asterisk or footnote marker next
to the SHOULD in the main list.

-d

---

From: "Mark D. Baushke" <[email-masked]>
Date: Tue, 13 Sep 2016 08:32:34 -0700

Tero Kivinen <[email-masked]> writes:

> > Group or not....
> Curdle charter says:
> CURDLE - CURves, Deprecating and a Little more Encryption
> 
...elided...
> so it seems to fit well to curdle charter, if we deprecate and collect
> mandatory to implement ciphers to one document. 

I agree.

> > 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...
>
> I would suggest we collect all "Algorithm Implementation Requirements
> and Usage Guidance for ssh" in one document here too.

Are we going to adopt all of the SSH changes at one IETF?

Right now, I am the author of two related drafts:

  draft-ietf-curdle-ssh-kex-sha2
  draft-ietf-curdle-ssh-modp-dh-sha2

they deal with updates to Key Exchange Algorithm Methods.

Of the current CURDLE documents
https://datatracker.ietf.org/wg/curdle/documents/

the only SSH drafts are:

  draft-ietf-curdle-rsa-sha2-02 
  draft-ietf-curdle-ssh-ed25519-00
  draft-ietf-curdle-ssh-ext-info-01
  draft-ietf-curdle-ssh-kex-sha2
  draft-ietf-curdle-ssh-modp-dh-sha2

and the rest are:

  draft-ietf-curdle-cms-chacha20-poly1305-01 
  draft-ietf-curdle-cms-ecdh-new-curves-01 
  draft-ietf-curdle-cms-eddsa-signatures-00
  draft-ietf-curdle-dnskey-eddsa-00 
  draft-ietf-curdle-pkix-01

I just realized that the

  draft-ietf-curdle-ssh-curves-00

draft has expired on September 9, 2016 and not been resubmitted, so
there is no ed25519-sha256 or curve448-sha512 KEX currently in an active
draft.

To the best of my understanding, no draft to add chacha20-poly1305 to
SSH similar to what has been added to OpenSSH has been written.

To the best of my understanding, no draft to fix the AEAD_AES_128_GCM
and AEAD_AES_256_GCM to negotiate in a way similar to OpenSSH have been
written.

Given the current drafts, they appear to impact only:

Key Exchange Method Names:
http://www.iana.org/assignments/ssh-parameters/
ssh-parameters.xhtml#ssh-parameters-16

Public Key Algorithm Names:
http://www.iana.org/assignments/ssh-parameters/
ssh-parameters.xhtml#ssh-parameters-19

Are there any other documents I have missed?

> In draft-ietf-ipsecme-rfc4307bis-12 for IKEv2 we even specified the
> mandatory to implement authentication methods, and recommended key
> lengths (see section 4.1.1). We also provide little bit of background
> reasoning for the MUST/SHOULD/MUST NOT/SHOULD NOT algorithms.

Okay.

	-- Mark

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 13 Sep 2016 13:53:18 +0300

Curdle charter says:

The CURDLE working group is chartered to add a small set of
cryptographic mechanisms to some IETF protocols, and to make
implementation requirements including deprecation of old algorithms
where there is IETF consensus to do so. ...
...
The protocols the WG intends to work on are Secure Shell (SSH), ...
...
The CURDLE working group will be handling changes to protocols and
registries some of which include what are now considered outdated
algorithm options, and may propose deprecation of such algorithms. ... 
...

> specifying the MUST/SHOULD/MAY/SHOULD NOT advise...

In IPsecME we did collect all IKEv2 related requirements to one
document, and all ESP/AH related requirements to another document. The
reason we have two documents is, because the requirements are
different. In IKEv2 it is ok to specify ENCR_AES_CBC as MUST, as it is
low speed link and performance is not primary goal. In ESP we also
make ENCR_AES_GCM_16 as MUST as it is needed for high performance
gateways.

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Tue, 13 Sep 2016 20:18:49 -0600

According to this page (great work by Max Horn):

http://ssh-comparison.quendi.de/comparison/kex.html

ecmqv-sha2 is listed with zero known implementations.

Note that this might be inaccurate – ext-info-s is also listed as having no implementations, whereas it has at least ours (Bitvise SSH Server 7.xx). But this is a new development (first released a few months ago), whereas RFC 5656 dates back to 2009. It might be safe to say that any implementations of ecmqv-sha2 are indeed very secretive.

denis

From: Mark D. Baushke 
Sent: Tuesday, September 13, 2016 13:21
To: Damien Miller 
Cc: Curdle ; IETF SSH 
Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 & draft-ietf-curdle-ssh-kex-sha2

-- Mark