[Curdle] AD Review of draft-ietf-curdle-ssh-kex-sha2-09

[Eric Rescorla <[e-mail]>]

See https://mozphab-ietf.devsvcdev.mozaws.net/D4046 for the review in
context.

I have two high-level concerns about this document.

The presentation is very confusing, with a lot of duplication and not much
in the way of general principles until we get to the Security
Considerations section. You should start by laying out your principles
(FFDH >= 2048, > SHA-1, ECC >= 256, etc.) and then have less text for each
of the suites unless there's something unobvious in one of them (e.g.,
we're keeping it around for compatibility).

Second, I am concerned about the appropriateness of embedding the NSA's
judgements about what algorithms are suitable for various classification
levels in an IETF RFC. First, the IETF is not a US ogranization. Second, we
are just now deprecating the suite B RFCs because NSA changed its mind
about how to structure things. I think we should largely confine our
comments to the IETF's judgements about what is or is not secure.

*INLINE COMMENTS*
View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4046#inline-2151>
draft-ietf-curdle-ssh-kex-sha2.txt:100
Method Names that MUST be implemented. Over time, what was once
considered secure, is no longer considered secure. The purpose of
this RFC is to recommend that some published key exchanges be

Nit: no comma here.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4046#inline-2152>
draft-ietf-curdle-ssh-kex-sha2.txt:107
Methods which MUST, SHOULD, MAY, SHOULD NOT, and MUST NOT be
implemented. New key exchange methods will use the SHA-2 family of
hashes found in [RFC6234] and are drawn from these ssh-curves from

Isn't this sentence duplicative of the previous sentence?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4046#inline-2153>
draft-ietf-curdle-ssh-kex-sha2.txt:128
implementation of MUST, SHOULD, SHOULD NOT, and MUST NOT. Any method
not explicitly listed, MAY be implemented.

Spurious comma here.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4046#inline-2154>
draft-ietf-curdle-ssh-kex-sha2.txt:137
be secure with wide enough adoption to upgrade their recommendation
from MAY to SHOULD or MUST.

This is not a sentence.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4046#inline-2155>
draft-ietf-curdle-ssh-kex-sha2.txt:141
The Curve25519 provides strong security and is efficient on a wide
range of architectures with properties that allow better

I would strike "The "

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4046#inline-2157>
draft-ietf-curdle-ssh-kex-sha2.txt:149
Method has multiple implementations and SHOULD be implemented in any
SSH interested in using elliptic curve based key exchanges.

"in any SSH implementation"

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4046#inline-2156>
draft-ietf-curdle-ssh-kex-sha2.txt:153
The Curve448 provides very strong security. It uses SHA2-512 (also
known as SHA-256) defined in [RFC6234] for integrity. It is probably

I would strike "The ". Also, I'm not sure characterizing 256 as "strong"
and 448 as "very strong" is that helpful. Isn't the general consensus that
256 bits of real security is fine unless there are quantum computers, in
which case all bets are off.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4046#inline-2158>
draft-ietf-curdle-ssh-kex-sha2.txt:155
known as SHA-256) defined in [RFC6234] for integrity. It is probably
stronger and more work than is currently needed. This Key Exchange
Method is described in [I-D.ietf-curdle-ssh-curves] and is similar to

This also seems unnecessary.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4046#inline-2159>
draft-ietf-curdle-ssh-kex-sha2.txt:162
This set of ephemerally generated key exchange groups uses SHA-1 as
defined in [RFC4419]. However, SHA-1 has security concerns provided

The groups aren't ephemeral. The keys are.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4046#inline-2160>
draft-ietf-curdle-ssh-kex-sha2.txt:185
still need to use this key exchange, it should be removed from server
implementations as quickly as possible.

; instead of ,

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4046#inline-2161>
draft-ietf-curdle-ssh-kex-sha2.txt:195
method will transition to SHOULD NOT when SHA-2 alternatives are more
generally available.

It would be useful to explain why SHA-1 is a concern here. Perhaps a
sentence about how SHA-1 is used?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4046#inline-2162>
draft-ietf-curdle-ssh-kex-sha2.txt:215
additional head room over the 2048-bit group14 FFC DH and the
predominate open source implementations are not adopting it. This
method MAY be implemented.

Why do you say it doesn't provide much security over 2048?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4046#inline-2163>
draft-ietf-curdle-ssh-kex-sha2.txt:226
This modulus (4096-bit) is larger than that required by [CNSA-SUITE]
and should be sufficient to inter-operate with more paranoid nation-
states. This method SHOULD be implemented.

interoperate does not have a hyphen

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4046#inline-2164>
draft-ietf-curdle-ssh-kex-sha2.txt:252
curve may not be as useful and strong as desired for handling TOP
SECRET information for some applications. The SSH development
community is divided on this and many implementations do exist. If

TOP SECRET seems like a very national-state specific term. Perhaps some
other term is appropriate. Is there a particular reason we are basing our
assessments on what USG likes.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4046#inline-2165>
draft-ietf-curdle-ssh-kex-sha2.txt:272
mean that this algorithm will need to be downgraded in the future
along the other ECDSA nistp curves.

how does this cipher suite use ECDSA? You don't say. Isn't it basically the
same as ecdh-sh2-nistp256

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4046#inline-2166>
draft-ietf-curdle-ssh-kex-sha2.txt:282
hash could mean that as many as nine bits of this key could be at
risk of leaking if appropriate padding measures are not taken. This
method MAY be implemented, but is not recommended.

Can you explain how this happens?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4046#inline-2167>
draft-ietf-curdle-ssh-kex-sha2.txt:290
security concerns [RFC6194]. It is recommended that these key
exchange groups NOT be used. This key exchange SHOULD NOT be used.
It is intended that it move to MUST NOT as soon as the majority of

These two sentences are duplicative.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4046#inline-2168>
draft-ietf-curdle-ssh-kex-sha2.txt:310
This key exchange method is defined in [RFC4462]. This generated key
exchange groups uses SHA-1 which has security concerns [RFC6194]. If

What's a "generated key exchange group"

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4046#inline-2169>
draft-ietf-curdle-ssh-kex-sha2.txt:563
DH groups to avoid pre-calculation attacks that are provably not
backdoored.

This sentence doesn't make any sense: it's not attacks that are backdoored.
More generally, are there in fact concerns that the FFDH groups were
maliciously generated, or just that they are too weak against
pre-calculation