Re: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH)

Tero Kivinen <kivinen@iki.fi> Mon, 17 July 2017 12:25 UTC

Return-Path: <kivinen@iki.fi>
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 5E9D0131B35 for <curdle@ietfa.amsl.com>; Mon, 17 Jul 2017 05:25:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 ahQURWJhSuHW for <curdle@ietfa.amsl.com>; Mon, 17 Jul 2017 05:25:38 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 553D9131B14 for <curdle@ietf.org>; Mon, 17 Jul 2017 05:25:38 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v6HCPXEq014494 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 17 Jul 2017 15:25:33 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v6HCPX4N016948; Mon, 17 Jul 2017 15:25:33 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <22892.44221.173699.599992@fireball.acr.fi>
Date: Mon, 17 Jul 2017 15:25:33 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Russ Housley <housley@vigilsec.com>
Cc: curdle@ietf.org
In-Reply-To: <A9F5E1BB-967B-4DA7-8E3D-7AE8CC06EA47@vigilsec.com>
References: <22892.35863.542104.942153@fireball.acr.fi> <A9F5E1BB-967B-4DA7-8E3D-7AE8CC06EA47@vigilsec.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 8 min
X-Total-Time: 8 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/Wn7-r8kRcRkj8ujSUFls1SehCNg>
Subject: Re: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH)
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: Mon, 17 Jul 2017 12:25:40 -0000

Russ Housley writes:
> I agree with Tero.  However, I like the use of SHOULD+ and MUST- to
> signal to project and product planners what is coming.   

Actually it is much better to explain that kind of things in the
actual text. For example:

3.5.  diffie-hellman-group14-sha1

   This method uses [RFC3526] group14 (a 2048-bit MODP group) which has
   no concerns.  This generated key exchange group uses SHA-1 which has
   security concerns [RFC6194].  However, this group is still strong
   enough and is widely deployed.  This method is being moved from MUST
   to SHOULD- to aid in transition to stronger SHA-2 based hashes. This
   method will transition to MUST NOT when SHA-2 alternatives are more
   generally available.


Gives much better information what to expect than SHOULD- in table.
SHOULD+, SHOULD- were useful when we only had table of requirement
levels. Now when we have the text about each algorithm explain the
reasoning, those + and - characters are getting more and more
meaningless.

For example the SHOULD- is defined in section 2 to mean that this
algorithm will be deprecated to MAY in future version, but in practice
we quite often go from SHOULD- to SHOULD NOT (or even MUST NOT, as the
text above suggests).

Anyways this is separate issue than wheter we should make
implementations having code for diffie-hellman-group1-sha1
non-conforming by publishing that implementations MUST NOT implement
diffie-hellman-group1-sha1...
-- 
kivinen@iki.fi