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, 09 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
- [Curdle] WGLC draft-ietf-curdle-ssh-kex-sha2 Daniel Migault
- Re: [Curdle] WGLC draft-ietf-curdle-ssh-kex-sha2 Daniel Migault
- Re: [Curdle] WGLC draft-ietf-curdle-ssh-kex-sha2 Mark D. Baushke
- Re: [Curdle] WGLC draft-ietf-curdle-ssh-kex-sha2 Daniel Migault
- Re: [Curdle] WGLC draft-ietf-curdle-ssh-kex-sha2 Benjamin Kaduk
- Re: [Curdle] WGLC draft-ietf-curdle-ssh-kex-sha2 Benjamin Kaduk
- Re: [Curdle] WGLC draft-ietf-curdle-ssh-kex-sha2 Daniel Migault
- Re: [Curdle] WGLC draft-ietf-curdle-ssh-kex-sha2 Mark D. Baushke