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

Benjamin Kaduk <kaduk@mit.edu> Tue, 30 July 2019 21:46 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5913120111; Tue, 30 Jul 2019 14:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWS7r7sdvpUU; Tue, 30 Jul 2019 14:46:08 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA4B7120074; Tue, 30 Jul 2019 14:46:05 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (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 <kaduk@mit.edu>
To: draft-ietf-curdle-ssh-kex-sha2.all@ietf.org
Cc: curdle <curdle@ietf.org>
Message-ID: <20190730214600.GR47715@kduck.mit.edu>
References: <CABcZeBO9yTFwc0aUBoMOEbESbxaPiPHpGFTpBH=5RKJogLS2vg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABcZeBO9yTFwc0aUBoMOEbESbxaPiPHpGFTpBH=5RKJogLS2vg@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/kf-iCb-o3yyxKLvH_pnGsxq7FVo>
Subject: Re: [Curdle] AD Review of draft-ietf-curdle-ssh-kex-sha2-09
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=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
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