Re: [Curdle] Looking for comments on draft-ietf-curdle-ssh-kex-sha2

Tero Kivinen <kivinen@iki.fi> Thu, 26 November 2020 17:09 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 BDAED3A14EF for <curdle@ietfa.amsl.com>; Thu, 26 Nov 2020 09:09:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi
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 vpvdW7fPORKa for <curdle@ietfa.amsl.com>; Thu, 26 Nov 2020 09:09:46 -0800 (PST)
Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::201]) (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 C93F23A14EA for <curdle@ietf.org>; Thu, 26 Nov 2020 09:09:45 -0800 (PST)
Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id 55A58200D6; Thu, 26 Nov 2020 19:09:42 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1606410582; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9tDsccOxMnzBG+5u9cOvvG11Hc9q83wbskBwQZ0Ufbs=; b=WLvk+g4ZCPHDzJyI0iYt8J+jER8Gkk4zbAXB0pYGvncVHTc69ubkNAQAWDIaKOf6Mqgdpc sdfsPkfjeCTNlpIt+3JJKPx4qSdGjYgx+HwBKsjmYQ9QnW9nQMnslxEPV2aQMM8R+ibZsT 6zgc+ah6+f0wND/2oUP6r8UOdIPX4kg=
Received: by fireball.acr.fi (Postfix, from userid 15204) id 3508425C19CF; Thu, 26 Nov 2020 19:09:41 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <24511.57685.169815.673441@fireball.acr.fi>
Date: Thu, 26 Nov 2020 19:09:41 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Hubert Kario <hkario@redhat.com>
Cc: <curdle@ietf.org>
In-Reply-To: <7107b6ac-0e6c-419d-96ac-d0a53b65ee5b@redhat.com>
References: <25423.1596646626@eng-mail01.juniper.net> <SA0PR15MB37917F0E55D801609AF23EB0E34B0@SA0PR15MB3791.namprd15.prod.outlook.com> <20200807052623.GM92412@kduck.mit.edu> <71619.1606168457@eng-mail01.juniper.net> <7107b6ac-0e6c-419d-96ac-d0a53b65ee5b@redhat.com>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 10 min
X-Total-Time: 9 min
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1606410582; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9tDsccOxMnzBG+5u9cOvvG11Hc9q83wbskBwQZ0Ufbs=; b=axOVBI00XYDigVNe7p3JMrkEdTc5b6mA/za5DGMmHhPY1mIP56XAVoRf5oPIt3gBNlPisK ZX6yBR6dsEjgla6S2NALWKKwNH2OzddIjOtuktJ007qhvuAfP+amIBq0GoWoz4C0nb2oro 9my7vn80nNVBMgDh15pHbOeP5r7+oac=
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi
ARC-Seal: i=1; s=meesny; d=iki.fi; t=1606410582; a=rsa-sha256; cv=none; b=AilNDt4Wf09qsySqFCg2nquWn/3TT87cQkJbV9E6rbF6jEmztPv2pZqt3Mp/PTsh8DVhWy WygCI6TPfqdUzn9b1ARjD/Om4Sxiw6rBD1jqoRHRcYIcFUD1hvhkXy3vAUeifNgTVY991e wKDDvkxJTGFyYyygflpQatF9wbZZMH8=
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/CDj-x48km_DbDzkeBuMCyEReqp8>
Subject: Re: [Curdle] Looking for comments on 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: Thu, 26 Nov 2020 17:09:49 -0000

Hubert Kario writes:
> > The diffie-hellman-group14-sha1 exchange was a mandatory to implement
> > MUST and is now a SHOULD. Similarly for gss-group1-sha1-*
> 
> no, I think it should be SHOULD NOT, the sha-1 disqualifies it

If I remember right about ssh key exchange, it does not rely on the
collision resistance at all, it relies on the 2nd preimage resistance,
i.e., for attacker to be able to attack ssh key exchange it needs to
get the signature generated by the server using random data created by
the server, and find out inputs to hash function that generates
exactly same hash than what server used to sign the exchange.

As on of the inputs is the server's diffie-hellman public key and the
final resultant secret, the attacker do not know these before server
replies, and thus it needs to do this attack in real time during the
connection establishment phase.

For such use cases sha-1 should be completely acceptable. The
group1-sha1 uses only 1024 bit diffie-hellman, and thats why it is
marked as SHOULD NOT. The group14-sha1 uses 2048 bit diffie-hellman
which is still considered acceptable for some uses. I.e., if you are
just protecting real time shell access to machine 2048 bits should be
enough, but it is not acceptable when transmitting data which needs to
keep secure for tens of years.

Actually the draft already explains this:
----------------------------------------------------------------------
   The SHA-1 hash is in the process of being deprecated for many
   reasons.  There have been attacks against SHA-1 that have shown there
   are weaknesses in the algorithm.  Therefore, it is desirable to move
   away from using it before attacks become more serious.

   At present, the attacks against SHA-1 are collision attacks that rely
   on human help rather than a pre-image attack.  So, it is still
   possible to allow time backward compatibility use of SHA-1 during a
   SSH key-exchange for a transition to stronger hashing.  However, any
   such key exchanges should be listed last in the preference list.
-- 
kivinen@iki.fi