Subject: Re: [Curdle] draft-ssorce-gss-keyex-sha2-00

From: "Mark D. Baushke" <[email-masked]>
Date: Sun, 16 Apr 2017 22:15:08 -0700

Hi Simo & Hubert,

Regarding your draft:
https://www.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.txt

The reference to the -05 I-D.ietf-curdle-ssh-kex-sha2 should probably be
replaced with a reference to draft-ietf-curdle-ssh-modp-dh-sha2-04

Likewise, I-D.draft-ietf-curdle-ssh-curves-00.xml should become
I-D.draft-ietf-curdle-ssh-curves-04.xml for now.

I am somewhat curious why the same curves identified in RFC5656 as
nistp256, nistp384, and nistp521 are being called secp256r1, secp384r1,
secp521r1 in your draft in section 6. Is there a good reason to select
this form of the names?

I will note that gss-secp384r1-sha512-* should probably be
gss-secp384r1-sha384-* to be consistent with how RFC5656
felt security should be handled.

I do know that there is some controversy about supporting SHA2-384
rather than SHA2-256 and SHA2-512, but it has been argued that SHA2-384
does not expose as much of its internal state as does SH2-512 and that
it aligns more closely with the nistp384 curve.

	-- Mark

---

From: Hubert Kario <[email-masked]>
Date: Wed, 19 Apr 2017 14:39:08 +0200

> replaced with a reference to draft-ietf-curdle-ssh-modp-dh-sha2-04

It probably should have references to both.
 
> secp521r1 in your draft in section 6. Is there a good reason to select

Because I took those names from TLS curve registry. Making them consistent 
with other SSH names is a good idea though. Thanks!

> felt security should be handled.

Good point.

> it aligns more closely with the nistp384 curve.

how is that applicable to the KEX?
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 19 Apr 2017 08:10:56 -0700

> It probably should have references to both.

The ietf-curdle-ssh-kex-sha2-08 is referencing your draft right now. I
am not sure a circular dependency is needed.

> > does not expose as much of its internal state as does SH2-512 and that

oops s/SH2/SHA2/

> how is that applicable to the KEX?

I am not sure it is, but it was originally argued that ECDH and ECDSA
should use the same hashing mechanisms. So, if ECDSA mandates SHA2-384
for a nistp384 curve, then using the same thing in ECDSA seems less
likely to cause confusion.

I only mentioned the SHA2-384 vs SHA2-512 issue if you wanted to add it
to your security considerations section. I regret that I was not clear
in my comment.

I hope my comments have made sense.

	-- Mark

---

From: Simo Sorce <[email-masked]>
Date: Fri, 21 Apr 2017 08:48:02 -0400

> I hope my comments have made sense.

Thank you Mark,
sorry for not commenting, I was on vacation, I will take on your changes
and release a new draft asap.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc