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

Benjamin Kaduk <> Tue, 30 July 2019 21:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B5913120111; Tue, 30 Jul 2019 14:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oWS7r7sdvpUU; Tue, 30 Jul 2019 14:46:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA4B7120074; Tue, 30 Jul 2019 14:46:05 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id x6ULk1W5014785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jul 2019 17:46:03 -0400
Date: Tue, 30 Jul 2019 16:46:01 -0500
From: Benjamin Kaduk <>
Cc: curdle <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [Curdle] AD Review of draft-ietf-curdle-ssh-kex-sha2-09
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Jul 2019 21:46:12 -0000

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



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