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
- [Curdle] AD Review of draft-ietf-curdle-ssh-kex-s… Eric Rescorla
- Re: [Curdle] AD Review of draft-ietf-curdle-ssh-k… Benjamin Kaduk
- Re: [Curdle] AD Review of draft-ietf-curdle-ssh-k… Mark D. Baushke