Re: [Curdle] Last Call: <draft-ietf-curdle-ssh-kex-sha2-14.txt> (Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)) to Proposed Standard

Benjamin Kaduk <kaduk@mit.edu> Sun, 28 February 2021 01:21 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 7B5C53A176F; Sat, 27 Feb 2021 17:21:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1ag7E_7UZGBV; Sat, 27 Feb 2021 17:21:16 -0800 (PST)
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 CE0693A176B; Sat, 27 Feb 2021 17:21:15 -0800 (PST)
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 11S1L5OT024761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 27 Feb 2021 20:21:09 -0500
Date: Sat, 27 Feb 2021 17:21:04 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Rene Struik <rstruik.ext@gmail.com>
Cc: "Mark D. Baushke" <mdb@juniper.net>, last-call@ietf.org, curdle@ietf.org, curdle-chairs@ietf.org, draft-ietf-curdle-ssh-kex-sha2@ietf.org, Daniel Migault <daniel.migault@ericsson.com>
Message-ID: <20210228012104.GV21@kduck.mit.edu>
References: <161297636786.23628.11474505782744804904@ietfa.amsl.com> <ef2702b2-deec-9d7f-2641-0d2b79e819c4@gmail.com> <27419.1614219147@svl-bsdx-06.juniper.net> <e51d89c1-30a6-bf87-5fbb-65ec5f51322f@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e51d89c1-30a6-bf87-5fbb-65ec5f51322f@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/_9xBp-YUu5eZ2EvS-clgdXmhoR4>
Subject: Re: [Curdle] Last Call: <draft-ietf-curdle-ssh-kex-sha2-14.txt> (Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)) to Proposed Standard
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: Sun, 28 Feb 2021 01:21:19 -0000

Hi Rene,

Picking just a couple points...

On Thu, Feb 25, 2021 at 10:39:24AM -0500, Rene Struik wrote:
> 
> On 2021-02-24 9:12 p.m., Mark D. Baushke wrote:
> >
> > Rene Struik <rstruik.ext@gmail.com> writes:
> >
> >> Dear colleagues:
> >>
> >> I did have a brief look at this draft and have the following (small)
> >> comments:
> >>
> >> Draft: draft-ietf-curdle-ssh-kex-sha2-14
> >>
> >> Comments:
> >> - the document seems to take a half-hearted stance on deprecating the
> >> use of SHA1. Why not simply strike all key exchange methods that use it
> >> off Table 6 altogether?
> > MDB:
> >
> > As the draft author, my original intention was to move all of the *-sha1
> > key exchanges to either deprecated or disallowed. In RFC keyword terms,
> > this is SHOULD NOT or MUST NOT. If you look at Table 6, the only one
> > that was missed was the former "MUST" algorithm
> > "diffie-hellman-group14-sha1" which has been moved from "MUST" by
> > RFC4253 to "MAY by this draft.
> >
> > The WG consensus was that this "MAY" allows for a transition period to
> > the new "MUST", "SHOULD", and "MAY" guidelines for key exchange methods.
> 
> RS>> Please note that IACR awarded the "test of time" award (see 
> https://www.iacr.org/testoftime/)(after 15 years) to
> 
>  From Crypto 2005:Finding collisions in the full 
> SHA-1<https://doi.org/10.1007/11535218_2>_2>, by Xiaoyun Wang, Yiqun Lisa 
> Yin and Hongbo Yu/For a breakthrough in the cryptanalysis of hash 
> functions./
> 
>     If people after 15 years still need time, crypto agility seems to be
>     a dead letter. Besides, RFCs are not laws: implementors always have
>     the option to ignore/reject whatever IETF produces. By stipulating
>     MUST NOT one at least forces implementers to justify themselves. {In
>     my mind, most security flaws are caused by sloppy implementors,
>     which gives everyone else also a bad name.}
>     //<<RS/

The "transition period" is not about time per se, as much as transitioning
an algorithm from "MUST implement" to "MUST NOT implement", with no
algorithms guaranteed to be available in "old" implementations that would
interoperate with "new" implementations.

Yes, we should have published a document to deprecate the SHA-1 algorithms
many years ago; we didn't.  As far as I can tell the best path forward is
to publish something like this now and come back in a year or two to finish
the transition to "MUST NOT".  Recall that continuing to debate will leave
SHA-1 as "MUST implement"!

> >> - in Section 3.2.2, I am somewhat puzzled by the suggested use of
> >> Curve448 with SHA512, since RFC8709 introduces Ed448 (which uses a
> >> 4-isogenous curve Edwards448 to Curve448, but which uses SHAKE256/d=914
> >> internally). Why not align the underlying hash functions, so that
> >> implementations with this curve would be able to use a single hash
> >> function implementation?
> > MDB:
> >
> > I thought the section 3.2.2 text was clear that the key exchange method
> > names were those found in RFC8731.
> >
> > Section 3.2.2 specifies curve25519-sha256 for two reasons:
> >
> >    a) it is a direct documentation of curve25519-sha256@libssh.org which
> >       is deployed in many SSH implementations and is documented in
> >       RFC8731.
> >
> >    b) SHA-3 implementation were not as widely deployed as SHA-2 when the
> >       curve25519-sha256@libssh.org implementation was created.
> >
> > If you have any suggestions for how to make section 3.2.2 clearer, I
> > have no pblems with updating the section with such a consideration to
> > help readers of the RFC.
> RS>> I simply wanted to suggest that specifications should aim for 
> lowering implementation cost, unless there are very strong reasons for 
> not doing so. BTW - my comment was about different hash functions used 
> with Curve448 and Ed448, not about curve25519. If one can write code for 
> Ed448 (which enforces the use of SHAKE256/d=914), why can't the key 
> exchange method do a call to that hash function with the key derivation 
> function? It is somewhat disturbing that one simply copies what a single 
> library does... <<RS

Note that curve448-sha512 was already specified in RFC 8731, so it is too
late to change anything about it.

I'll echo others' thanks for the feedback; the extra review is appreciated.

-Ben