Re: [Curdle] WGLC draft-ietf-curdle-ssh-kex-sha2

Benjamin Kaduk <> Wed, 10 February 2021 02:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6B153A11EC for <>; Tue, 9 Feb 2021 18:22:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id csyf7jlCC5ne for <>; Tue, 9 Feb 2021 18:22:04 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D7F433A11EA for <>; Tue, 9 Feb 2021 18:22:03 -0800 (PST)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 11A2Ltir018016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 9 Feb 2021 21:22:00 -0500
Date: Tue, 9 Feb 2021 18:21:55 -0800
From: Benjamin Kaduk <>
To: "Mark D. Baushke" <>
Cc: Daniel Migault <>, curdle <>
Message-ID: <>
References: <> <> <45081.1612307585@eng-mail03>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <45081.1612307585@eng-mail03>
Archived-At: <>
Subject: Re: [Curdle] WGLC draft-ietf-curdle-ssh-kex-sha2
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: Wed, 10 Feb 2021 02:22:06 -0000

Hi Mark,

On Tue, Feb 02, 2021 at 03:13:05PM -0800, Mark D. Baushke wrote:
> Hi all,
> Daniel Migault <> writes:
> > Thanks Mark for the follow-up as well as for pushing the updated
> > version considering the feed backs received during the WGLC. We am
> > planning to proceed to a request for publication in the next coming
> > days. So, if one of your concerns has not been address please let the
> > mailing list know.
> > 
> > Yours,
> > Rich and Daniel
> > 
> > [1]
> ...elided...
> As I write this, I have received no additional comments in the last
> seventeen days.

Thanks for following up.

I went through the -13 -- the changes since the -12 make sense to me.
That said, I think we will want a -14 before issuing IETF LC, mostly
just to tidy up some editorial stuff that would keep the genart reviewer
busy and make it harder to read for other reviewers -- I'll send an
edited XML file with my take on those fixes to help get them out

There were a few things that I wanted to mention separately, though:

The shepherd writeup was last modified in 2018 and should probably get
an update to reflect the recent WG review and input, before the draft
gets to IESG Evaluation.

The table in the IANA considerations disagrees about the implementation
recommendation for gss-group16-sha512-* with the table in Section 3.3.2
(SHOULD vs MAY) -- your previous messages to the list suggest that MAY
is intended, and I mostly assume that the SHOULD crept in during the
rewrite for the -12, when making the non-GSS group16 method 'SHOULD'.

There's also a line in Section 3.2.3 (ecdh-*, ecmqv-sha2, gss-nistp*)
that says "this set of methods MAY be implemented" when the tables and
other prose say "SHOULD" about ecdh-sh2-nistp*.  The "MAY" would line up
with ecmqv-sha2, that otherwise is not mentioned in this section other
than the table, but ecmqv-sha2 is not really a "set" of methods.
I'm not sure what the intent was for that text (maybe it's just stale?);
my current proposal is to just remove it, but that doesn't do anything
to address the lack of prose about ecmqv-sha2 in this section.  (It might
also have been referring to the general set other than the specific named

I also went through the references, with these comments:

Section 8.1

RFC 8031 is just about curve25519/curve448 for IKEv2, and I don't see a
need for them to be normative references for us -- 8731 is (AFAIK) the
relevant SSH reference.

Section 8.2

We may get some people asking for RFCs 4419, 4432, 4462, 5656, 8731, and
8732 to be moved to normative references.  In my opinion it's debatable,
so I'm happy to leave them as-is for now -- they're all standards track,
so there would not be a process issue if we had to move them after the

I'll include the editorial notes below for visibility and in case they
help Mark decipher my proposed changes, but I don't expect anything
noteworthy that's not (also) mentioned above.




Section 1.1

> At present, the attacks against SHA-1 are collision attacks that
> usually rely on human help rather than a pre-image attack. 

nit: I think a comma before "rather than" would help.

> Transcript Collision attacks are documented in [TRANS-COLL]. This
> paper shows that the man in the middle does not tamper with the
> Diffie-Hellman values and does not know the connection keys. However,
> it manages to tamper with both Ic and Is, [...]

nit: it looks like RFC 4253 writes these as "I_C" and "I_S" (though
maybe native subscripts are better yet).

Section 1.2.1

> For ECC, it is recommended to select one with approximately 128 bits
> of security strength.

nit: s/one/a curve/

Section 1.2.2

> For FFC, a modulus 2048 bits (112 bits of security strength).

editorial: it's not clear what this not-quite-sentence is trying to say.
If we wanted parallelism with §1.2.1, it would be "it is recommended to
use a modulus with 2048 bits (112 bits of security strength)", but since
after the table we go and list an explicit minimum of 2048-bit MODP
group14 it's not entirely clear that that's the intent.

Section 1.2.3

> The only IFC algorithm for key exchange is the RSA algorithm via
> [RFC4432]. 

nit: s/via/specified in/

Section 3.1

> diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1 are
> currently mandatory to implement (MTI). [...]

I'd suggest avoiding "currently" (due to the ambiguity of whether it
applies to the state of affairs before or after the publication of this
document, when the reader will be reading it after publication) and
favoring "prior to the changes made by this document, [...] were
mandatory to implement".

> SHA-1 has security concerns provided in [RFC6194].

nit: s/provided/documented/ or something like that

Section 3.2.1

> These key exchange methods are described in [RFC8731] and [RFC8732]
> and is similar to the IKEv2 Key Agreement described in [RFC8031].

nit: singular/plural mismatch "are described"/"is similar".

Section 3.2.2

> This Key Exchange Method is described in [RFC8731] and is similar
> [...]

nit: since we added gss-curve448-sha512-* to this section we have to go
to "methods are described" and "are similar" just as in §3.2.1.

> This method MAY be implemented.

nit: may also need to reword this to just cover curve448-sha512.

Section 3.2.3

> At present, there are three named curves in this name-space which
> SHOULD be supported. They appear in [RFC5656] in section 10.1 Required
> Curves all of the NISTP curves named are mandatory to implement if any
> of this RFC is implemented.

nit: "at present" may not age as well as "at the time of this writing".

nit: I think the intent was maybe to format this as """section 10.1
("Required Curves").  All of the NISTP curves named therein are
mandatory to implement if any of that RFC is implemented".

> This set of methods MAY be implemented.

Is this sentence stale text?  AFAICT it refers to the same
ecdh-sha2-nistp* that are SHOULD elsewhere in the section.
But if it referred to ecmqv-sha2 then the "MAY" would make more sense.

> The GSS-API name-space with gss-nistp*-sha* mirrors the algorithms
> used by ecdh-sha2-* names. The table provides guidance for
> implementation.

This would be a good place to put a reference to RFC 8732.

Section 3.3.1

> [RFC8270] mandates implementations avoid any MODP group

nit: "mandates that"

Section 3.3.2

> diffie-hellman-group14-sha256 method MUST be implemented.

nit: "The".

Section 3.4

> Uses an RSA 2048-bit modulus with a SHA2-256 hash.

nit: "It uses"

Section 6

> It is desirable to deprecate or remove key exchange method name that
> are considered weak. A key exchange method may be weak because too few
> bits are used, or the hashing algorithm is considered too weak.

nit: this is not an exhaustive list, so we could tweak the wording.