[Curdle] comments on draft-ietf-curdle-ssh-kex-sha2-05

Daniel Migault <daniel.migault@ericsson.com> Sun, 26 March 2017 19:29 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 1719512968A for <curdle@ietfa.amsl.com>; Sun, 26 Mar 2017 12:29:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level:
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 QHVhgK7vNDHi for <curdle@ietfa.amsl.com>; Sun, 26 Mar 2017 12:29:47 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 57D90129689 for <curdle@ietf.org>; Sun, 26 Mar 2017 12:29:47 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id 190so33071158itm.0 for <curdle@ietf.org>; Sun, 26 Mar 2017 12:29:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=6tlJDYPd9CMTN+wYNfOy2hQ3fmpTCOH4DbNGDaAHm3U=; b=ay7aXNBuVA3TE0aCkgTlVpIMSqm2Vdo0fwraDVtbr4y+dH3z1tX8oR6Qa9QVeOmeOB gKpi3XNQepkw1ti7W2y4SQalJklY+6eCxHauhJFw688zLLJDGTMTY9iyuHR7ZblHi7In Blb2TS404Sqodt5uqMBRYKP4MOOQcpKtm10B1ndIP2WZD9BjGgpUuHUFIH1qFVa1S5mv Y+Zx9d6vDSnhhbt0r9CfTNVGlUF9HXrP/lWBVaTqWnza4XSwFm1c1bBTU/9mFAKdFrnR L/Kd1UUJB+JoN2MBKuiGxUsxCVvfSJuTsdzQGSjSIDlqUCk0D/v+UQmKPy9OjLdS/8zp ty1Q==
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:from:date:message-id:subject :to; bh=6tlJDYPd9CMTN+wYNfOy2hQ3fmpTCOH4DbNGDaAHm3U=; b=JLnrGC26IdFl/5NW7amYY1EX4C0vDuOptuWXrm7LmG3CmzjnL7eGz57tbAD96G9HPV wdmUK3VJglfUIBojSW/8GPzV7WesqzHucSfiM4OoInEfBEUZ/zDdlDApPXXKOywZNlKM 3l/FT/bksCarFZyEC71/Wk1W670MZqGUnRtriCfNg2pC7NmTWczQzrLuES2QjPW/MKXK 8mTMCSy7l2AbqO8NmMOBnJVLSMFpo5AWHYoiMgYfWuXLVbA7TfyNCbVlTGkxMamWAFkw O7J4gXinYn4oBUqewFn2AbGEvPphvFpQEMZfhf5YR17bv58AyNi1d3GPUEBERS1mxPj+ iR2Q==
X-Gm-Message-State: AFeK/H0KKBEZu/9DWfH3d1KpN+wAn2t6eJgTuGZ8jWGgMq2y0fY64/SOSs649erw1LSiu3xP1CgoYlE37XonGQ==
X-Received: by 10.36.175.5 with SMTP id t5mr6422998ite.48.1490556586414; Sun, 26 Mar 2017 12:29:46 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.107.35.213 with HTTP; Sun, 26 Mar 2017 12:29:45 -0700 (PDT)
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Sun, 26 Mar 2017 14:29:45 -0500
X-Google-Sender-Auth: YpqoxPmvKR0QArIiBTJ598F6_CU
Message-ID: <CADZyTkmyY-hTOn8HhYNjKU43DDVHKZn1aM2oQjeSvKJCNjmzzw@mail.gmail.com>
To: curdle <curdle@ietf.org>
Content-Type: multipart/alternative; boundary="f403045dc12ad9d9d3054ba73f1b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/taKa1rhbTHka8Fs2MpgctOQ8rf4>
Subject: [Curdle] comments on draft-ietf-curdle-ssh-kex-sha2-05
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: Sun, 26 Mar 2017 19:29:49 -0000

Hi,

Please find some comments of draft-ietf-curdle-ssh-kex-sha2-05.

Yours,
Daniel

I have the impression that only RFC4253 provided some recommendations, in
which case I would be incline to say that the current draft only updates
this document. The other RFC only defines new suites.

I suggest we either use MUST/SHOULD/MAY or REQUIRE/RECOMMEND/OPTIONAL but
not both. Note that if the recommendations for ipsec
[draft-ietf-ipsecme-rfc4307bis] we also introduced some additional notation
such as SHOULD+/- to specify whether the SHOULD is expect to raise its
status or that SHOULD is only here for interoperability.

Note that recommendations are not the purpose of IANA, so I would probably
change the title of the section. The IANA only adds the code points. It is
god that you mentioned the IANA link. I would encourage you to have the URL
as an informative  reference.

Recommendations should regularly updated so implementations have the time
to introduce new suites or remove old suites while still providing
interoperability. If the starting point is RFC4253, then we have:

      diffie-hellman-group1-sha1 REQUIRED
      diffie-hellman-group14-sha1 REQUIRED

and all other suites are OPTIONAL or MAY. Correct me if I am wrong, At
least I believe that that appendix section would be useful to comment on
the update with the previous recommendations.

       curve25519-sha256                    ssh-curves MUST

Maybe a MUST statement may be to strong as curves have just been defined.
Maybe that could be SHOULD+ mentioning it is expected to become a MUST next
time. In fact it is usually hard to move from MAY to MUST. If you do so,
reasons should be provided in the text. Currently it seems it is
implemented in libssh and OpenSSH, not sure it is sufficient for a MUST.

        curve448-sha512                      ssh-curves MAY
By default, the suites with MAY status are not mentioned.

        diffie-hellman-group-exchange-sha1   RFC4419    SHOULD NOT
SHA1 is probably at MUST NOT, so I am expected any suites to be MUST NOT.
Because it represents a threat you are likely to move to MUST NOT directly.

        diffie-hellman-group-exchange-sha256 RFC4419    MAY
        diffie-hellman-group1-sha1           RFC4253    SHOULD NOT
If group 1 is 768-bit MODP Group , I would consider there are two reasons
to have this as MUST NOT.

        diffie-hellman-group14-sha1          RFC4253    SHOULD
My understanding is that this one is kept for interoperability. However,
the text should make it clear this suite will be deprecated soon.

        diffie-hellman-group14-sha256        new-modp   MUST
        diffie-hellman-group15-sha512        new-modp   MAY
        diffie-hellman-group16-sha512        new-modp   SHOULD
        diffie-hellman-group17-sha512        new-modp   MAY
        diffie-hellman-group18-sha512        new-modp   MAY
        ecdh-sha2-nistp256                   RFC5656    SHOULD
        ecdh-sha2-nistp384                   RFC5656    SHOULD
        ecdh-sha2-nistp521                   RFC5656    SHOULD

The current trend is also to reduce the number of suites implementation. DO
we want to have these three suites as SHOULD. We should also explain what
the next step is expected to be.


        ecdh-sha2-*                          RFC5656    MAY
        ecmqv-sha2                           RFC5656    SHOULD NOT
        gss-gex-sha1-*                       RFC4462    SHOULD NOT
        gss-group1-sha1-*                    RFC4462    SHOULD NOT
        gss-group14-sha1-*                   RFC4462    SHOULD
        gss-group14-sha256-*                 new-modp   SHOULD
        gss-group15-sha512-*                 new-modp   MAY
        gss-group16-sha512-*                 new-modp   SHOULD
        gss-group17-sha512-*                 new-modp   MAY
        gss-group18-sha512-*                 new-modp   MAY
        gss-*                                RFC4462    MAY

        rsa1024-sha1                         RFC4432    SHOULD NOT
Maybe we could set it as MUST NOT both for key size and SHA1.

        rsa2048-sha256                       RFC4432    MAY