Subject: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange)

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 13 Jan 2016 01:21:06 -0800

Hi,

URL: https://datatracker.ietf.org/doc/draft-baushke-ssh-dh-group-sha2

I believe that OpenSSH and Dropbear SSH have both implemented interoperable
versions using the current 01 version at this point in time.

I would be interested in hearing if any other implementations have
adopted these new DH groups.

Are there any additional comments or changes needed for the draft before
we can move to the next step in the process?

Hmmm... What is next? Getting 'AD is watching' or is it getting a
document shepherd?

	Thank you,
	-- Mark

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Jan 2016 10:34:05 +0000

Hiya,

> Hmmm... What is next? Getting 'AD is watching' or is it getting a

There's no active SSH WG, but there is the curdle WG. Its
charter [1] however is limited in terms of what it's
allowed to add to protocols. OTOH, this is not defining any
new groups, just updating codepoints, including deprecating
one (to NOT RECOMMENDED). So the draft could fit there on
that basis I guess. So I'd say send a mail to the curdle
list and suggest this be adopted there.

If that doesn't work I can look at AD sponsoring it, but
since one of the reasons to setup curdle was to avoid too
many of these being AD sponsored, please try there first.

Cheers,
S.

[1] https://tools.ietf.org/wg/curdle

---

From: IWAMOTO Kouichi <[email-masked]>
Date: Tue, 19 Jan 2016 12:27:38 +0900

Hi, 

On Wed, 13 Jan 2016 01:21:06 -0800

> adopted these new DH groups.

I know three ssh clients for windows that support diffie-hellman-group{14,15,16}-sha256.

RLogin  http://nanno.dip.jp/softlib/man/rlogin/  (available Japanese version only)
  RLogin supports dh-group{14,15,16}-sha256 since version 2.19.8.

Tera Term (ttssh)  https://ttssh2.osdn.jp/
  dh-group{14,15,16}-sha256 support was committed to trunk, and it will be included in next release.
  https://en.osdn.jp/projects/ttssh2/scm/svn/commits/6263

Poderosa  http://poderosa.sourceforge.net/
  I wrote dh-group{14,15,16}-sha256 support patch, and sent pull-request.
  https://github.com/poderosaproject/poderosa/pull/17 (wrote in Japanese)

Thanks,

-- 
IWAMOTO Kouichi ([email-masked]/[email-masked]/[email-masked])

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 27 Jan 2016 09:19:24 -0800

Hi Folks,

> URL: https://datatracker.ietf.org/doc/draft-baushke-ssh-dh-group-sha2

I just noticed that the Information Assurance Directorate at the NSA has
a new article on 'CNSA Suite and Quantum Computing FAQ' ... their URL is

https://www.iad.gov/iad/library/ia-guidance/ia-solutions-for-classified/algorithm-guidance/cnsa-suite-and-quantum-computing-faq.cfm

Reading the document, they are mandating that NSS no longer use
Diffie-Hellman with 2048-bit keys instead they are suggesting
IETF RFC 3526 (Groups 15-18).

They are also no longer interested in using SHA-256 wanting SHA-384.

For folks interested in compliance with the CNSA Suite, does it make
sense for the baushke-ssh-dh-gorup-sha2 ID to be updated to specify
either SHA-384 (or possibly SHA-512)?

That is change from this:

   Key Exchange Method Name          Note
   diffie-hellman-group1-sha1        NOT RECOMMENDED
   diffie-hellman-group14-sha256     RECOMMENDED
   diffie-hellman-group15-sha256     RECOMMENDED
   diffie-hellman-group16-sha256     OPTIONAL

to this:

   Key Exchange Method Name          Note
   diffie-hellman-group1-sha1        NOT RECOMMENDED
   diffie-hellman-group14-sha256     RECOMMENDED
   diffie-hellman-group15-sha384     RECOMMENDED
   diffie-hellman-group16-sha384     OPTIONAL
   diffie-hellman-group17-sha512     OPTIONAL
   diffie-hellman-group18-sha512     OPTIONAL

I am suggesting sha512 for group17 and group18 as a minor bit of
future-proffing and/or performance trade-off for sha512 hardware
acceleration that may exist.

Comments please?

	-- Mark

---

From: Damien Miller <[email-masked]>
Date: Thu, 28 Jan 2016 10:08:40 +1100 (AEDT)

> either SHA-384 (or possibly SHA-512)?

I'd skip SHA-384 entirely in favour of SHA-512. Vendors who implement
Ed25519 will have a SHA512 implementation around anyway, whereas
~nobody uses SHA-384.

Also, I think it makes sense to reduce the number of groups offered.
OpenSSH is only offering 14 and 16 now, but might do 18 in the future.
We don't see any need for incremental steps between.

So my recommendation would be:

diffie-hellman-group1-sha1        NOT RECOMMENDED
diffie-hellman-group14-sha256     RECOMMENDED
diffie-hellman-group16-sha512     RECOMMENDED
diffie-hellman-group18-sha512     OPTIONAL

(but 16+256 & 18+512 would be fine too)

-d

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 29 Jan 2016 04:27:43 +0000

[email-masked] <[email-masked]> writes:

>I just noticed that the Information Assurance Directorate at the NSA has a
>new article on 'CNSA Suite and Quantum Computing FAQ' ... their URL is
>

My response to this, on the CFRG list, was:

>On the QC stuff. Of course we have to start looking at that now. But I think
>we need to look at the problem on two separate tracks:
>
>1) Find a public key algorithm that resists QC using Shorr's algorithm.
>2) Find a mechanism that makes symmetric key feasible in place of public.

You forgot step 0:

0) Figure out whether any of this stuff is actually necessary

This is just a bunch of random numbers pulled out of thin air, just as Suite B
was in its day, and CCEP was before that.  There's no empirical argument
supporting any of this, just a huge what-if.  For all we know the entire
document could have come about from a barroom bet, "Well Bill, you had them
chasing the Suite B white elephant, Dave got them really good with Dual-EC,
now it's my turn to see how high I can make them jump.  And best of all, TAO
will love me for it because they'll have to throw out most of their already-
deployed, partially-patched-up infrastructure and start again, leading to lots
of new exploitable mistakes and errors".

If you're worried about QC, why aren't you worried about TWINKLE/TWIRL, which
is at least as feasible, if not more so, than QC, and has been around much
longer?

If the NSA wants to put forward a new white elephant to supplant Suite B and
the rest, hand them a can of paint and point them at the nearest zoo.  In the
meantime I'll stick with addressing problems that are actual problems, there's
more than enough of those to go round.

Peter.

---

From: [email-masked] (Niels Möller)
Date: Fri, 29 Jan 2016 22:13:36 +0100

Damien Miller <[email-masked]> writes:

> I'd skip SHA-384 entirely in favour of SHA-512.

Agreed. SHA-384 has the same security as truncated SHA-512 (just
differing initial values). And I don't see any point in doing truncation
for the ssh key exchange hash, am I missing anything?

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.