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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 30 Jul 2019 16:46:01 -0500

I took over as responsible AD for this draft from Eric, but I don't
see any response to these review comments.  I don't think we can move the
document forward without some discussion (and presumably a new rev of the
document).

Thanks,

Ben

On Sat, Feb 24, 2018 at 01:28:19PM -0800, Eric Rescorla wrote:
> 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

---

From: "Mark D. Baushke" <[email-masked]>
Date: Tue, 30 Jul 2019 15:16:57 -0700

Hi Ben,

I did send private email to Eric suggesting that this draft should wait
until the other drafts had been published and all of CURdle could come
to consensus on what needs to be recommended or not.

My goal was to have a vehicle to deprecate diffie-hellman-group1
completely from a REQUIRED group to one that should not be supported and
the rest of the document was trying more to be a best practice document.
(I suspect it failed at conveying that.)

	-- Mark