Re: [Curdle] draft-ietf-curdle-rc4-die-die-die-06 review

Daniel Migault <daniel.migault@ericsson.com> Fri, 06 July 2018 21:13 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 2FDF7130F62 for <curdle@ietfa.amsl.com>; Fri, 6 Jul 2018 14:13:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 SRZvfDKIBN44 for <curdle@ietfa.amsl.com>; Fri, 6 Jul 2018 14:13:45 -0700 (PDT)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 2E2D7130DE3 for <curdle@ietf.org>; Fri, 6 Jul 2018 14:13:45 -0700 (PDT)
Received: by mail-lf0-x231.google.com with SMTP id u202-v6so10803794lff.9 for <curdle@ietf.org>; Fri, 06 Jul 2018 14:13:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=/UHos086Gurw2NVDs29lqRLvXsV1T3ehkmCT8n4Rdc8=; b=IFc0RriVERHN8v+ug2O15AELYHqTWuMVAU6aN6JsT7VlwRkmy94504aOn5E6UC3kEO RBJoFIJbu4pEU4uDvEEbDLtye1UrcGmUocQCX9VXBfpPAEbGhTwzWe9Iof1hHSgqrDPf eWycNsd4Yn1A0HjfDPid+fv1hpSfD+yMS0ror1fv83u73MtTYJiQw69nu2tL0j9pA/mY TsSF2JOseiZfWl5H9LjOwJnRDoUzn7BWliwonU0V5/NdNugOuz55NNWZF4a50/EbJjxr iQznfq1hd5VYQAQh77GxE1qSiqkTc7uhvYx8jmzqkLLBwnG7oYdaOmKQJUVaxyXkjDU1 nL8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=/UHos086Gurw2NVDs29lqRLvXsV1T3ehkmCT8n4Rdc8=; b=tbD/XDtkJNTCGGsH/0ETYi9392B/0N0ckI6/C7j2tqng0+BtNJ4KmrkxQRSY6LUHYf EjCQG789lnaqlTLAtxfu47R8mAgw8UkinYS0ispfCOb2zSVjnb98BKHM/AHrNpLFIsdV 5Fp+5zWvqJigZGRE8Mr1XCuAyRG2BJKLEiwEd9klg86uzbgZSA38FFI6MfnVXSqWD/wT bh2V0YHCBONzV7QoaRA8fh5cUTWzvrf8WRWYHsgA4ueNalRA+VAUPzA2aQn5XsDgTD6v N3BX4AtCAzIPRKZ5m9/mOpa9uE1NUxxEWYAencfPniX3j4ZRsr/PTWClr1ypZ9n16h5k GjAQ==
X-Gm-Message-State: APt69E1XGPX50wBDyFnInoMDcvHmuVVWHgXCO7v5VIS1ul6J5LoAfN0j xiCRegjr9fTquzDYzBv8S1NnH1xf3SfIZ2XJfrQ=
X-Google-Smtp-Source: AAOMgpc9KHcvu/vJEA1oBTOqEd/Ixw26Gf/mDl2Zpc0rUlFBoF7gALSsnZ+Hwx0JVkcezejqb8vCiUi/20ewqPdg/Vk=
X-Received: by 2002:a19:6902:: with SMTP id e2-v6mr8087110lfc.70.1530911623195; Fri, 06 Jul 2018 14:13:43 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 2002:a2e:119d:0:0:0:0:0 with HTTP; Fri, 6 Jul 2018 14:13:42 -0700 (PDT)
In-Reply-To: <CADZyTkkv=m7N2ztwfqz2M4C=maai1-Djyfwrf4TzL3Pt=-ujdg@mail.gmail.com>
References: <CADZyTkkv=m7N2ztwfqz2M4C=maai1-Djyfwrf4TzL3Pt=-ujdg@mail.gmail.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Fri, 06 Jul 2018 17:13:42 -0400
X-Google-Sender-Auth: LzGkTtIiTj9tmw0N30HqKK3dEaM
Message-ID: <CADZyTkn-AtKgn4Z28NUfu1fOjN6XV43m1uNWf_ge3T6_0o0pbQ@mail.gmail.com>
To: curdle <curdle@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007bb06c05705b23df"
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/E80zKVnLuz4Yku25T5DDvPb6t_o>
Subject: Re: [Curdle] draft-ietf-curdle-rc4-die-die-die-06 review
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.26
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: Fri, 06 Jul 2018 21:13:49 -0000

Hi,

We would like to move the draft to the IESG, however, the draft has not
been updated to address the comments received on the mailing list. We have
privately contacted the author 3 times with the email address provided to
the draft, but we did not receive any response. The purpose of this email
is to first try to contact the author of draft via another channel and
understand if he has any plan to move the draft forward. In addition, we
would also like to see if there is any interest by some members of the
group to co-author the draft and move the draft forward. For those
interested in co-authoring the draft, please contact us privately.

Our goal is to have all drafts - that is the two remaining drafts in WGLC -
submitted by end of august.

Yours,
Rich and Daniel

On Tue, May 15, 2018 at 1:00 PM, Daniel Migault <daniel.migault@ericsson.com
> wrote:

> Hi,
>
> Please find my review for draft-ietf-curdle-rc4-die-die-die-06 [1]. I
> have also proposed text, so please comment the review in the mail. I am
> willing to start a WGLC as soon as the draft is being updated.
>
> Yours,
> Daniel
>
>
> [1] https://tools.ietf.org/html/draft-ietf-curdle-rc4-die-die-die-06
>
>
> RFC-Editor:
>
> I personally find the ton of the sentence a bit aggressive, thus I would
> remove it or just leave the RFC reference.
>
> """
> Non-ASCII characters are allowed in RFCs as per RFC 7997.
> """
>
> I see deprecation and move to historic status as very similar to
> draft-ietf-curdle-des-des-des-die-die-die-05 and I assume that is
> correct.
>
> Abstract:
>
> The sentence below is a bit hard to parse.
> ""
> and formally obsoletes and moves to
>    Historic RFC 4345.
> ""
>
> I would propose instead:
>
> """
> This document deprecates RC4 in Secure Shell (SSH).  Therefore, this
>    document updates RFC 4253, and moves to Historic RFC 4345.
> """
>
> 1. Introduction
>
>
> """
> RC4 is broken""
> """
>
> Although English is not my main language, it sounds a bit abrupt to me and
> it might be preferred to sue something around the lines of
> draft-ietf-curdle-des-des-des-die-die-die-05:
>
> RC4 encryption is steadily weakening in cryptographic strength, and the
> deprecation process should be begun for their use in SSH.
>
>
> It seems to me that sections 1, 2 3 could be merged. I would propose the
> following text. I am providing comments in <mglt></mglt>.
>
>
>
> 1. Introduction
>
>
> The usage of RC4 suites ( also designated as arcfour ) for SSH are
> specified in RFC 4253 and RFC 4345. RFC 4253 specifies the allocation of
> the "arcfour" cipher for SSH. RFC 4345 specifies and allocates the the
> "arcfour-128" and "arcfour-256" ciphers for SSH.
>
> RC4 encryption is steadily weakening in cryptographic strength
> [RFC7457][draft-ietf-curdle-des-des-des-die-die-die-05], and the
> deprecation process should be begun for their use in Secure Shell (SSH)
> [RFC4253]. Accordingly, RFC 4253 is updated to note the deprecation of the
> RC4 ciphers and RFC 4345 is moved to Historic as all ciphers it specifies
> MUST NOT be used.
>
> <mglt>I believe that this document is very closed to
> [draft-ietf-curdle-des-des-des-die-die-die-05] and as such a reference to
> it should be mentioned. </mglt>
>
>
> 2.  Requirements Notation
>
>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in BCP 14 [RFC2119, RFC8174]
> when, and only when, they appear in all capitals, as shown here.
>
> 3. Updates to RFC 4253
>
> RFC 4253 is updated to prohibit arcfour's use in SSH.
>
> <mglt>
> """
> The last sentence of the paragraph on RC4 (called "arcfour"
>    in [RFC4253]) in Section 6.3 of [RFC4253]
> """
>
> I believe that it might be clearer to quote the text as it is not easy to
> locate it. I would propose the text below. </mglt>
>
> RFC 4253 allocate the "arcfour" cipher in Section 6.3 by defining a list
> of defined ciphers where the "arcfour" cipher appears as optional as
> mentioned below:
>
> """
>       arcfour          OPTIONAL          the ARCFOUR stream cipher
>                                          with a 128-bit key
> """
>
> The current document updates the status of the "arcfour" ciphers in the
> list of RFC 4253 Section 6.3 by moving it from OPTIONAL to MUST NOT.
>
> """
>       arcfour          MUST NOT          the ARCFOUR stream cipher
>                                          with a 128-bit key
> """
>
> RFC 4253 defines the "arcfour" ciphers with the text mentioned below:
> """
>    The "arcfour" cipher is the Arcfour stream cipher with 128-bit keys.
>    The Arcfour cipher is believed to be compatible with the RC4 cipher
>    [SCHNEIER].  Arcfour (and RC4) has problems with weak keys, and
>    should be used with caution.
> """
>
> The current document updates RFC 4253 Section 6.3 by replacing th etext
> above with the following text:
>
> """
>    The "arcfour" cipher is the Arcfour stream cipher with 128-bit keys.
>    The Arcfour cipher is believed to be compatible with the RC4 cipher
>    [SCHNEIER].  Arcfour (and RC4) is steadily weakening in cryptographic
> strength [RFC7457][draft-ietf-curdle-des-des-des-die-die-die-05], and
>    MUST NOT be used.
> """
>
> 4. IANA Considerations
>
> <mglt>There is a reference to 3DES i think should be removed. In addition,
> IANA cannot be required to update RFCs. IANA is assigned to update the SSH
> registries. With [IANA] being an informational reference to
> https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml,  I
> would propose the following text :</mglt>
>
> The IANA is requested to update the Encryption Algorithm Name  Registry of
> the Secure Shell (SSH) Protocol Parameters [IANA]. The Registration
> procedure is IETF Review which is achieved by this document. The registry
> should be updated as follows:
>
> Encryption Algorithm Name     Reference     Note
> arcfour                          [RFC-TBD]
> arcfour128                     [RFC-TBD]
> arcfour256                     [RFC-TBD]
>
>
> Where TBD is the RFC number assigned to the document.
>
>
>
>