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

Tero Kivinen <kivinen@iki.fi> Thu, 26 November 2020 20:46 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 822C23A0E52 for <curdle@ietfa.amsl.com>; Thu, 26 Nov 2020 12:46:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, URIBL_BLOCKED=0.001] autolearn=unavailable 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 ri9SzU7bDlol for <curdle@ietfa.amsl.com>; Thu, 26 Nov 2020 12:46:17 -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 EA1CB3A0EA9 for <curdle@ietf.org>; Thu, 26 Nov 2020 12:46:16 -0800 (PST)
Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (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 3F1FD200CC; Thu, 26 Nov 2020 22:46:13 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1606423573; 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=LrwJG3Xug1kAwyG0rUQ0m80YZkwAP3KmELtSjozHR7c=; b=lMs3m/Iu8EaLrhcf02NIX+zbt3akABl95JXZZrQZzjmPwQdyllDdmmJlDB3gRTlklKBbWn Tft9/sGhndDn/Vz4BuUf+L3w+/Q6ogbGTHGxVqYVnwCblzClmKxMUS8OE7Ca2NyHgYWNHG Ar47eDjvGCcp7MEVKymwk7MK6hU3lUg=
Received: by fireball.acr.fi (Postfix, from userid 15204) id D890925C0E38; Thu, 26 Nov 2020 22:46:12 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <24512.5140.838958.415785@fireball.acr.fi>
Date: Thu, 26 Nov 2020 22:46:12 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: "Mark D. Baushke" <mdb=40juniper.net@dmarc.ietf.org>
Cc: Hubert Kario <hkario@redhat.com>, curdle@ietf.org
In-Reply-To: <6050.1606417649@eng-mail01.juniper.net>
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> <24511.57685.169815.673441@fireball.acr.fi> <afea8fb0-82e2-46e9-b2cc-4dca4038b630@redhat.com> <6050.1606417649@eng-mail01.juniper.net>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 11 min
X-Total-Time: 15 min
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1606423573; 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=LrwJG3Xug1kAwyG0rUQ0m80YZkwAP3KmELtSjozHR7c=; b=gH0As2AZiFsDh1J9hCgi78w0LDmd71IbCypv2wNOdFH100w8w/UPfVrLpJArCrNtCSm43X wStZ6XUviGprc5ATHH1RXq2zggMoXm2ks9cijz7dfdeLs4yE79VRNwpDv/yXXE8bHYNwJp m4dL23ZtqNAndYIB6FHsWrS6DgJHi+M=
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=1606423573; a=rsa-sha256; cv=none; b=dtMd6LXEBSDPo5nLQyVK/Sf7lQYQP7dMylPr/oDhD7qtMP7RVADJkHLEBdtRNMKhhKEUuD pEli+AQ3T6cecVyzAtGeJTYDAcPJ9+Nm32NhiTwMzG1AYa8/RLrNoVx7i/5tYSvFp6KmHp i+6KdGQBS/NWAX2mfT5b7Qu58F5kFyc=
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/nk7X-nj-YtYl44k-_lBTTm4skrk>
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 20:46:20 -0000

Mark D. Baushke writes:
> I could add this informative reference:
> 
>     Karthikeyan Bhargavan, Gaeutan Leurent. Transcript Collision Attacks:
>     Breaking Authentication in TLS, IKE, and SSH. Network and Distributed
>     System Security Symposium -- NDSS 2016, Feb 2016, San Diego, United
>     States. 10.14722/ndss.2016.23418 . hal-01244855
>     URL: https://hal.inria.fr/hal-01244855/document
> 
> to the informative section of the RFC and try to add additional
> theoretical justification against SHA-1, is this really necessary?

I think it would be good idea to add that reference, even when it do
consider that attack against ssh impractical with 2^77 work, but it do
warn about not including weak ciphers in the list, and warn about the
group exchange. 

> The paper does show that the group exchange (RFC4419) use of *-sha1 may
> be somewhat easier to attack than the fixed group, but I have already
> listed that as 'SHOULD NOT' in my -12 draft.

This could refer to this same paper.

> The real question here is if "SHOULD NOT" is the correct implementation
> guidance for all use of diffie-hellman-group14-sha1 in key exchanges
> which is a big jump from "MUST" right now. All of the other *-sha1
> exchanges in the draft are listed as "SHOULD NOT" already.

I think it can still be SHOULD, just to keep backward compatibility
with old devices. It does not need to be enabled by policy in default
configuration, but sometimes you need to connect those devices, and it
is painful if you need to find old version of some ssh client just to
be able to connect to them.
-- 
kivinen@iki.fi