|
According to this page (great work by Max Horn):
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
Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 &
draft-ietf-curdle-ssh-kex-sha2 Damien
writes: > 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 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. > > gss-group14-sha1-* RFC4462 SHOULD > > gss-group14-sha256-* new-modp SHOULD > > IMO these two should be MAY. Most implementations don't support > 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 _______________________________________________ Curdle mailing list Curdle%ietf.org@localhost https://www.ietf.org/mailman/listinfo/curdle |