Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange)

nisse@lysator.liu.se (Niels Möller ) Mon, 15 February 2016 18:52 UTC

Return-Path: <bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org>
X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3591A9030 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Mon, 15 Feb 2016 10:52:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.606
X-Spam-Level:
X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] autolearn=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 o56IaITv7UIG for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Mon, 15 Feb 2016 10:52:04 -0800 (PST)
Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (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 BC1131A8AD3 for <secsh-tyoxbijeg7-archive@lists.ietf.org>; Mon, 15 Feb 2016 10:52:04 -0800 (PST)
Received: by mail.netbsd.org (Postfix, from userid 605) id BF7A485F94; Mon, 15 Feb 2016 18:52:03 +0000 (UTC)
Delivered-To: ietf-ssh@netbsd.org
Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 5F14385E3C for <ietf-ssh@netbsd.org>; Mon, 15 Feb 2016 18:52:01 +0000 (UTC)
X-Virus-Scanned: amavisd-new at netbsd.org
Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 9jdQoBDkqF8w for <ietf-ssh@netbsd.org>; Mon, 15 Feb 2016 18:52:00 +0000 (UTC)
Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 7466784CFD for <ietf-ssh@netbsd.org>; Mon, 15 Feb 2016 18:51:59 +0000 (UTC)
Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id C4DFC40059; Mon, 15 Feb 2016 19:51:57 +0100 (CET)
Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 288D640056; Mon, 15 Feb 2016 19:51:55 +0100 (CET)
Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Mon, 15 Feb 2016 19:51:55 +0100
From: nisse@lysator.liu.se
To: "Mark D. Baushke" <mdb@juniper.net>
Cc: denis bider <ietf-ssh3@denisbider.com>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, Simon Josefsson <simon@josefsson.org>, ietf-ssh@netbsd.org
Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange)
References: <223360780-3264@skroderider.denisbider.com> <86136.1455402404@eng-mail01.juniper.net> <nnziv256db.fsf@armitage.lysator.liu.se> <27854.1455556432@eng-mail01.juniper.net>
Date: Mon, 15 Feb 2016 19:51:55 +0100
In-Reply-To: <27854.1455556432@eng-mail01.juniper.net> (Mark D. Baushke's message of "Mon, 15 Feb 2016 09:13:52 -0800")
Message-ID: <nnsi0t6c38.fsf@armitage.lysator.liu.se>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: ClamAV using ClamSMTP
Sender: ietf-ssh-owner@NetBSD.org
List-Id: ietf-ssh.NetBSD.org
Precedence: list

"Mark D. Baushke" <mdb@juniper.net> writes:

> That said, is it desirable to also make one of the MODP Diffie-Hellman
> groups also be a MUST? 

Not sure. But *if* we decide on two REQUIRED curves, I think it makes
sense to let one of them be a modp curve.

>> 2. Make it possible for a conforming implementation to support only one
>>    of sha256 and sha512.

> I am not sure I follow this line of reasoning. I have seen most
> libraries that implement one of the SHA2 family of functions tends to
> have an implementation for all members of the family.

The concern is more about binary size than source code. If you want a
compliant ssh implementation inside your toaster or sensor node, with
only a poor microcontroller inside. Then everything you can cut away
helps. If we don't care about formal compliance for such devices, this
argument becomes weaker.

> The key here is the phrase 'foreseeable future' and for that I want to
> be a bit more forward-looking and would very much like to see SHA2-512
> if there is a negative bias in other publications for SHA2-256 still
> being used as a cryptographic primitive.

My understanding is that a secure hash algorithm with 256 bits output
is a very strong primitive. If there's a problem with sha256, it isn't the
too short digest size (might be in other applications, where the
attacker can win by finding arbitrary collisions, with "only" 128 bit
difficulty), but structural problems which allows the attacker to take
short cuts. And the likelyhood of that is hard to put a number on.

I'm not strongly opposed to sha512. If we go for it, I think it's
preferable to not have any sha256 with status MUST. And as someone else
mentioned, if we believe eddsa25519 is going to be widely used, then
it's an advantage to use sha512 in the key exchange too, to be able to
cut away sha256 in the constrained implementation.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.