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

Daniel Migault <mglt.ietf@gmail.com> Wed, 10 February 2021 02:33 UTC

Return-Path: <mglt.ietf@gmail.com>
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 1E9FB3A1216 for <curdle@ietfa.amsl.com>; Tue, 9 Feb 2021 18:33:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 sb9dzP9tB064 for <curdle@ietfa.amsl.com>; Tue, 9 Feb 2021 18:33:22 -0800 (PST)
Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 B1D273A121C for <curdle@ietf.org>; Tue, 9 Feb 2021 18:33:22 -0800 (PST)
Received: by mail-ua1-x934.google.com with SMTP id a31so86986uae.11 for <curdle@ietf.org>; Tue, 09 Feb 2021 18:33:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xb3LpbvVxm921HuWM5aGo4QVnmh32Puo5b2PUf3t5DM=; b=VRaIn4q1nqN0AReeM9d4CRWHsZFybwdLxys1IoCgJfCbl5urO0c2GlVLyHhHIsFwkO /EFEOHhc6Xbb8ZUUvPLaXevmWTkVj+256meuoJFPhkHiDLueU48o+eGLREisKeyON9Ln Yw4n1MdwUz4NjZM0hacVihso4NP3wVlleQE3nEARq6cpjipPdLyHJwTvN0oNa64fFFAe iV/cBglWAiK0UaAxC3S4PR2mf3YnHj3A/e+n9GaIFk+jzqg7HkQFEGPkB40GIU81563J kiHQI2Cyml888kpXggkCZLtCeA6rl2LZB07GHdxVxcHLFlhPEh69j/Ywz3/45EjCtUMq MVUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xb3LpbvVxm921HuWM5aGo4QVnmh32Puo5b2PUf3t5DM=; b=L2Cr6SzUQ3dD6AzyXYlGnrdHWe0KKu89qgRMAm1GmaGTJgWKL9c9pupAHNqLZAgFNj Sbu/s+BBmyPuCzK9PpjRu7G+pADBM8tRd3ch0bH//FqB6qjcbPYGPT6tMTcslJlkoiup 7kzNnVbVie/F0sLI/tFmh0cbNxh8POznBBoFGaxv2aWWl6eTFfHLmpl2vd837dt0tOWL Qw23bHqx+/Gic2GinBXWtqgYBTiIAObl2SlnkdteNeB8j56sCs092tYXGTbYW85BgUGq HRQTzlBBYv+TGVfT1V8B/RhCLXUAR736eT+LJ2aRVBEuuttTrJaCPerO2QIkaO8ggV7W e37A==
X-Gm-Message-State: AOAM531MuiQXZJnXPlXMDvbJ/SgoeJ1sLobDxHA2nZUA0ezT8rX6eTrJ zRspu5DpR+bt8yjjG1aV4HJqzaL6KZaD0NJXytQ=
X-Google-Smtp-Source: ABdhPJxM2zpsZDVb3t+K/kejVZt61q0Y2KFrZyuDsod7oNBqHvnZgXMh5WloZ5qh3fZlBWLlEYOHqh99CTneKnjbniw=
X-Received: by 2002:ab0:5b88:: with SMTP id y8mr487585uae.0.1612924401743; Tue, 09 Feb 2021 18:33:21 -0800 (PST)
MIME-Version: 1.0
References: <CADZyTkkTg0HV5EmxmVX7+Dqu7u7ufhycRtSSM06e=acnWzEj7A@mail.gmail.com> <CADZyTknLG1D2r3tqMGKinfMz7bZQRupLupVE_3gSqjLXkQWEaA@mail.gmail.com> <45081.1612307585@eng-mail03> <20210210022155.GG21@kduck.mit.edu>
In-Reply-To: <20210210022155.GG21@kduck.mit.edu>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Tue, 9 Feb 2021 21:33:10 -0500
Message-ID: <CADZyTk=M1zCXxWy_K2qcHPukLe787uGTrp+gN_TzXbGOiLnrLw@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: "Mark D. Baushke" <mdb=40juniper.net@dmarc.ietf.org>, curdle <curdle@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000003ff1005baf23a18"
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/OZRw-v_xA7y3aMNwxsnKyrhql0w>
Subject: Re: [Curdle] WGLC draft-ietf-curdle-ssh-kex-sha2
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: Wed, 10 Feb 2021 02:33:25 -0000

On Tue, Feb 9, 2021 at 9:22 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

> Hi Mark,
>
> On Tue, Feb 02, 2021 at 03:13:05PM -0800, Mark D. Baushke wrote:
> > Hi all,
> >
> > Daniel Migault <mglt.ietf@gmail.com> 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] https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/
> >
> > ...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
> quickly.
>
> 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.
>
> <mglt>I think this is on me.</mglt>


> 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
> curves.)
>
> 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
> IETF LC.
>
> 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.
>
> Thanks,
>
> Ben
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> 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.
>


-- 
Daniel Migault
Ericsson