Subject: [Curdle] AD Review: draft-ietf-curdle-ssh-modp-dh-sha2-05.txt

From: Eric Rescorla <[email-masked]>
Date: Sat, 17 Jun 2017 12:23:45 -0700

TECHNICAL
   The United States Information Assurance Directorate at the National
   Security Agency has published a FAQ [MFQ-U-OO-815099-15] suggesting
   both: a) DH groups using less than 3072-bits, and b) the use of SHA-2
   based hashes less than SHA2-384, are no longer sufficient for
   transport of Top Secret information.  For this reason, the new MODP
   groups are being introduced starting with the MODP 3072-bit group 15
   are all using SHA2-512 as the hash algorithm.

Unless I've badly misunderstood the situation, this rationale doesn't
make much sense. The security requirements for a digest algorithm
when used as part of a KDF are very different than those where it
is used to make a digital signature. Is collision resistance a required
security property for the KDF in the SSH key exchange? If so, why?

S 5.
These security estimates are very very old and I note that
keylength.com estimates are all over the place, but suggest
that at least some of these numbers may now be too optimistic.
(For instance, the Lenstra updates equations predict
that 3027 is 111 bits strong).

In any case, you need to explain what this table means.
I.e., what is the exponent size, because it's not clear just
from reading this document.

Also, you should state whether these are safe primes or not.

EDITORIAL
   The United States Information Assurance Directorate at the National
   Security Agency has published a FAQ [MFQ-U-OO-815099-15] suggesting
   both: a) DH groups using less than 3072-bits, and b) the use of SHA-2

both -> that both

   based hashes less than SHA2-384, are no longer sufficient for
   transport of Top Secret information.  For this reason, the new MODP

remove "the"

   groups are being introduced starting with the MODP 3072-bit group 15
   are all using SHA2-512 as the hash algorithm.

all use

   The DH 2048-bit MODP group 14 is already present in most SSH
   implementations and most implementations already have a SHA2-256
   implementation, so diffie-hellman-group14-sha256 is provided as an
   easy to implement and faster to use key exchange for small embedded
   applications.

faster than what? 3072 and 512?

S 5.
   Using a fixed set of Diffie-Hellman parameters makes them a high
   value target for precomputation.  Generating additional sets of
   primes to be used, or moving to larger values is a mitigation against
   this issue.  Care should be taken to avoid backdoored primes ([SNFS])
   by using "nothing up my sleve" parameters.

I'm not sure what the point of this last sentence is. Maybe you want
to claim that that's how these were generated? Also, "sleeve"

---

From: "Mark D. Baushke" <[email-masked]>
Date: Sun, 18 Jun 2017 09:52:32 -0700

Hi Eric,

I will rework the rationle and the security considerations sections to
address your concerns.

Question: Is it your contention that we should be able to use SHA256 for
all of the new MODP groups because the internal state of the hash will
always have more bits than the maximum amount of entropy in the
Diffie-Hellman shared secret?

	Thank you,
	-- Mark

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 18 Jun 2017 18:00:13 -0700

> Diffie-Hellman shared secret?

Yeah, that's kind of where I was going with this. Note that TLS 1.3 allows
SHA-256 with every kind of group, including P-384 and X448, so there is
some precedent. That said, I agree that SHA-512 is fine for this and so
if that's the WG's preference or there's some technical reason I'm not aware
of, I don't see a problem with SHA-512.

-Ekr

---

From: denis bider <[email-masked]>
Date: Mon, 19 Jun 2017 10:29:33 -0600

I have a strong preference to keep the groups and hashes as they are, and
only clarify the rationale, if necessary.

I'm not sure that it is necessary to clarify the rationale, because it is
not meant to be an appeal to cryptographic theory, it's an appeal to market
authority. The argument being made here is not that SHA-256 is
insufficient, it's that there's a substantial market which requires SHA-384
or SHA-512.

On Sun, Jun 18, 2017 at 7:00 PM, Eric Rescorla <[email-masked]> wrote:

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Jun 2017 10:10:31 -0700

Hmm... I can't get a copy of that sheet, but I'd be interested to see if it
it really says that you can't use SHA-256-based KDFs.

---

From: denis bider <[email-masked]>
Date: Tue, 20 Jun 2017 08:08:03 -0600

It pretty much says "anything below SHA-384 ist verboten". I was able to
find the document here:

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

It's in a PDF that you can download. To open the page in the first place,
you may likely need Firefox, which allows you to add a security exception
(the website's TLS certificate is signed by a DOD authority, instead of by
a public CA).

On Mon, Jun 19, 2017 at 11:10 AM, Eric Rescorla <[email-masked]> wrote:

> Hmm... I can't get a copy of that sheet, but I'd be interested to see if
> it it really says that you can't use SHA-256-based KDFs.
>
>