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

Eric Rescorla <ekr@rtfm.com> Sat, 24 February 2018 21:29 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0B143124B18 for <curdle@ietfa.amsl.com>; Sat, 24 Feb 2018 13:29:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id OwTgZUeZqhkq for <curdle@ietfa.amsl.com>; Sat, 24 Feb 2018 13:29:01 -0800 (PST)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5907D1241F5 for <curdle@ietf.org>; Sat, 24 Feb 2018 13:29:01 -0800 (PST)
Received: by mail-qk0-x22f.google.com with SMTP id l206so14949510qke.1 for <curdle@ietf.org>; Sat, 24 Feb 2018 13:29:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=QLMaxJH0Vx1p+xsaIyab/JJ5Z1NpnOvul31QO9ydimY=; b=dITPx8Byox9HD1XUN1zpjQ7SSR59a2gVJ4vbNcSN6o8+vahgena597k7GDlM6b6a4r XMXEVdxFdt5aNcOWErFAWqbtXUJAVljLZtuGNVIMl0xlejP9C6ou1cYcr8ikB5O9fUH2 zdYIAK+vJik5YfNe72XEsWKpcOZzWUhUb4Z9rMDD5yve6LEko2+V6A7pj5Jy7o8kcmhj U7ufbfFX3dK4AuzB7jJTjW8dcXrOGFOF99tCyPYDKf2EAsjQ08FCnwRL/KypAlPq2o/l 2tAjgHSysDVwzLUKB4xVIaCnvXuNyge7HgltrmkCSQxdoEtwxJcw3xKvybeHJlxLY3+B oJJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=QLMaxJH0Vx1p+xsaIyab/JJ5Z1NpnOvul31QO9ydimY=; b=OEV6YZyOu3/KApgqzPl0926VJaj5tXZjcFWVNCAQs/sGt4k/5nE495MdeeYtFF7Z9w EV7c5coa+C+HUqBfNdN8tSphx0DOMAthzuH1o+3c2USpIcXKnlWEVqiWnU63TDvdAz7r k+ycIlDSytyEL7P3NzYgID3RUXVSXq6tRaBJBKComoC5JuXduKixDhchwSm6ddRpjSIF hhAKqXfJIro+HBWUQ7iRt+41Ug0zAI/sWaz675dhDwZERdhvf3m5KzjfO5I7KF2vinOh 51ATLzck5HoE3jxw5TiqTYxwVf3GFjbBuSEQNCCENL9LotD/7SjQ0nNFox6+0ZlsC+SF 6zTQ==
X-Gm-Message-State: APf1xPBgiNPqK7kh+QCx4ssFbzPumDks30dFw86FiA+qLrms5Lrgnlwu CN0uNER04Z/svDFcaoNgd3MnbATTLnQWYQ9E77LIgjfjU+0=
X-Google-Smtp-Source: AG47ELsqY5SkxhcqkpCYVFO13u7BF/VucGFp0rehReTrFws2Aq1QtxxJSQgkwZbfCKuuIZXOFEPsAUubd2YYi6xsS9k=
X-Received: by with SMTP id b1mr9712272qkc.98.1519507739939; Sat, 24 Feb 2018 13:28:59 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sat, 24 Feb 2018 13:28:19 -0800 (PST)
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 24 Feb 2018 13:28:19 -0800
Message-ID: <CABcZeBO9yTFwc0aUBoMOEbESbxaPiPHpGFTpBH=5RKJogLS2vg@mail.gmail.com>
To: curdle <curdle@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0571b812a6870565fbf715"
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/dBmwgurWGiFJ-TMhoGMEK3i4Il8>
Subject: [Curdle] AD Review of draft-ietf-curdle-ssh-kex-sha2-09
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 24 Feb 2018 21:29:04 -0000

See https://mozphab-ietf.devsvcdev.mozaws.net/D4046 for the review in

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 <https://mozphab-ietf.devsvcdev.mozaws.net/D4046#inline-2151>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
DH groups to avoid pre-calculation attacks that are provably not

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