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

"Mark D. Baushke" <mdb@juniper.net> Tue, 18 August 2020 06:37 UTC

Return-Path: <mdb@juniper.net>
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 C7EB83A17B7 for <curdle@ietfa.amsl.com>; Mon, 17 Aug 2020 23:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=Gg39CLgx; dkim=pass (1024-bit key) header.d=juniper.net header.b=SHAqioQI
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 f6tYwGii7P-0 for <curdle@ietfa.amsl.com>; Mon, 17 Aug 2020 23:37:49 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 C700B3A17B6 for <curdle@ietf.org>; Mon, 17 Aug 2020 23:37:49 -0700 (PDT)
Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07I6bmQ8019319; Mon, 17 Aug 2020 23:37:48 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-transfer-encoding : date : message-id; s=PPS1017; bh=kSNR3DCIOKdxas1itUA0AUhZj2o0HmCepVfEEF/w/Dk=; b=Gg39CLgx3OEtHBP4FQ+a2idQOelLucDD8d/j1uFPsKKLM474oX3HYWiRU/VN1wEwAGy3 q11a9Vq4zSsyJthUbxb1xGe2D5cCi5UePHVviMdPzx5H5PM/LLb/I7QGSe4wiq5uS6Vq CMWwZJ+I86Rzi72Dcy3b2Lq5KPNyoAtC4VtIDaJR33cbuO9KrN43I+tJ4APlY85/Yv78 rLnqmpkAH2+Lfu8ptqzFjdukvHj2jXtnvZe4TeqgRTfBGxYOMFaFGOmTQSwXaR7IbA3u alS/DyEn+EZbhlem3/G4NdP+scLxaI/llfL0xjOPKAwYQuS7ramhmlzDf/nJOq2A5WQG pw==
Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2102.outbound.protection.outlook.com [104.47.58.102]) by mx0b-00273201.pphosted.com with ESMTP id 3304jr8dja-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Aug 2020 23:37:39 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hO227sSdnWvT/uvhlNGelcwQLcaIxDbUTbmlDJXj08tmCLmbIMAmnh1bUe/d2QAKUne1ToihTI6XrqNgoNthQju7p5kZZIqI12xZsFuiqreLTjesKc5UsuS5XiJbiFt/TBZIgcwnMW1HR+kpmim/IEBqhezFkF+hFy8G/LbctWK4eXV2/gwVQhtIV9mzXojR0W2palgZHbutSbdz6sg7SE+xUDnBIVpm1a7qQI/gNp3IOjv9ELLHAxs383yxvzKXiJ+US29Ea0boB8KjxvRwdvMOJ2LEFJvhdmA3e2frZaRreF+xOn/nfFhUHnZPHps62AW764PM1HkRi7GpSs8AcA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kSNR3DCIOKdxas1itUA0AUhZj2o0HmCepVfEEF/w/Dk=; b=JVC6aeqrUnacwc/1AgQ2duhYd8Re+dAHc8aVuW6509EXb+eM4YuKJThRjM+GQofq9KghFEBLrL+6Bg6O9RckqhPfH5c1izKTJhM69vGkVQIxnv40lcR4KE8RZdf6OTEvvhoLPOKyYxM4co2AKcaGj8aLh9sy3KhnFY1P+/MJyJigDXKQlKqAXMxtcvHFbAbvOs6DC5AA5Ef8o38wNrzOu2tk6s/rDiCyAjxCwG2QQPW1WCJMpH+Fn25Hezg3r/76MqeK3UddybDAwnlcdg/4Or1GBuw7wCGEpRGdpixqnoYfTp7SfqQdChbbr1hKVHQp/sANwSaQYmtCfYn5XqIphw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.13) smtp.rcpttodomain=ietf.org smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kSNR3DCIOKdxas1itUA0AUhZj2o0HmCepVfEEF/w/Dk=; b=SHAqioQIdPjsK9cx/eqpoCYujozrNsrnZ7wJfgt+t5GEO+2CrH5aTL8X2oDkXEsqPZqtbI4UMB+3uAIwxn8FXvJ6N6Lzln9IDkHEBZvlhX4YBAcXxQiQaWwLjNxFyDNoiJjAY6yjSNHsJM7dtGVnEtUxvzAw2gp8EawjDaHtLjc=
Received: from CO1PR15CA0111.namprd15.prod.outlook.com (2603:10b6:101:21::31) by DM6PR05MB5867.namprd05.prod.outlook.com (2603:10b6:5:10e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.17; Tue, 18 Aug 2020 06:37:37 +0000
Received: from CO1NAM05FT041.eop-nam05.prod.protection.outlook.com (2603:10b6:101:21:cafe::aa) by CO1PR15CA0111.outlook.office365.com (2603:10b6:101:21::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.18 via Frontend Transport; Tue, 18 Aug 2020 06:37:36 +0000
X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.13) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=oreject header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.13 as permitted sender)
Received: from P-EXFEND-EQX-02.jnpr.net (66.129.239.13) by CO1NAM05FT041.mail.protection.outlook.com (10.152.96.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.3305.15 via Frontend Transport; Tue, 18 Aug 2020 06:37:36 +0000
Received: from P-EXBEND-EQX-02.jnpr.net (10.104.8.53) by P-EXFEND-EQX-02.jnpr.net (10.104.8.55) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 17 Aug 2020 23:37:35 -0700
Received: from P-EXBEND-EQX-01.jnpr.net (10.104.8.52) by P-EXBEND-EQX-02.jnpr.net (10.104.8.53) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 17 Aug 2020 23:37:35 -0700
Received: from p-mailhub01.juniper.net (10.104.20.6) by P-EXBEND-EQX-01.jnpr.net (10.104.8.52) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 17 Aug 2020 23:37:34 -0700
Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [10.160.0.88]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 07I6bX6v002633; Mon, 17 Aug 2020 23:37:33 -0700 (envelope-from mdb@juniper.net)
To: Ron Frederick <ronf@timeheart.net>
CC: <curdle@ietf.org>
In-Reply-To: <346A7E8A-0060-471E-A547-055CAB147FC5@timeheart.net>
References: <25423.1596646626@eng-mail01.juniper.net> <D290968F-2733-40CB-918A-452AD74951B6@timeheart.net> <80066.1597703675@eng-mail01.juniper.net> <346A7E8A-0060-471E-A547-055CAB147FC5@timeheart.net>
Comments: In-reply-to: Ron Frederick <ronf@timeheart.net> message dated "Mon, 17 Aug 2020 22:42:40 -0700."
From: "Mark D. Baushke" <mdb@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 17 Aug 2020 23:37:33 -0700
Message-ID: <91994.1597732653@eng-mail01.juniper.net>
X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: c85f88b1-6a46-422d-c819-08d8434131ec
X-MS-TrafficTypeDiagnostic: DM6PR05MB5867:
X-Microsoft-Antispam-PRVS: <DM6PR05MB5867F92E6721A38AD94A9632BF5C0@DM6PR05MB5867.namprd05.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: QyESze8yhpUEgHZmCAgwzxXvrl3NV+8eNgZFOEttAu4+dlvMrvtnyceWUee3qoCcRojrUIPiHNS1fwz1pbVTTBLY6M80DkVxX1JqPwqmeQsme5I5LJspoN5AUzahYKLxIAheyz9yNlwkyx4SRUa2NHa59R02nMZwveG/a7sIeqG97nWzaITMuV6IZtJqNsJs8jpE8XAC7UWoHcMhpga0FRr9mHyII+g55Yoy8iqpAxgbNuvswwZxRVByQepeNRB9NgYrmCoi+KsplPN4KpDcFrSqR+YOs0z3DPidRliV70A6VrUEFf4O+TOpcah6v7Rxj+msDprmqVaAz3iSB7/epKhzqV8wic3lHRVfKxiQqSqZqkJ1rwf3qC+Tjso+Udtrasnv7pUg7GNhDhftYkUhAiI/jinM/fNhjNWjElTl9Pd+WEsWxoByUsKwHK1zoO57JO7PIwWNnw9uGMU+W1EA/7+l6y2nXiK8BOw8eTbQxAMOqC9YfipTsAUalkwMUzSxhPJIkFcIyf+wHM/IGL3YtS+LsdYJcok+A8hkasQ2ync=
X-Forefront-Antispam-Report: CIP:66.129.239.13; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:P-EXFEND-EQX-02.jnpr.net; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(4636009)(376002)(39860400002)(396003)(346002)(136003)(46966005)(8936002)(26005)(426003)(5660300002)(8676002)(82740400003)(4326008)(186003)(356005)(86362001)(82310400002)(6916009)(83380400001)(2906002)(70586007)(81166007)(966005)(83080400001)(336012)(7696005)(316002)(70206006)(478600001)(47076004)(43620500001)(15398625002); DIR:OUT; SFP:1102;
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2020 06:37:36.1373 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c85f88b1-6a46-422d-c819-08d8434131ec
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.13]; Helo=[P-EXFEND-EQX-02.jnpr.net]
X-MS-Exchange-CrossTenant-AuthSource: CO1NAM05FT041.eop-nam05.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5867
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-18_04:2020-08-18, 2020-08-18 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxlogscore=999 clxscore=1015 suspectscore=0 mlxscore=0 malwarescore=0 impostorscore=0 phishscore=0 spamscore=0 adultscore=0 priorityscore=1501 bulkscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008180045
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/cUst3M2B0FRzvbaD80k7RxLTa_k>
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: Tue, 18 Aug 2020 06:37:52 -0000

Ron Frederick <ronf@timeheart.net> writes:

> On Aug 17, 2020, at 3:34 PM, Mark D. Baushke <mdb@juniper.net<mailto:mdb@juniper.net>> wrote:
> Ron Frederick <ronf@timeheart.net<mailto:ronf@timeheart.net>> writes:
> - I noticed you dropped diffie-hellman-group14-sha256 back from MUST
>  to SHOULD, leaving no algorithms listed as MUST. I’d still like to
>  see at least one algorithm be listed as MUST, and think this is
>  probably the safest candidate for that.
> 

MDB wrote:
> How long is a 2048-bit prime, even with such a large q-ordered
> subgroup likely to remain viable?
> 
> 1024-bits for:
> 
>  a) IFC RSA,
>  b) FFC DSA, and
>  c) FFC DH,
>  d) as well as FFC DH group5 (1536-bits)
> 
> are all considered too weak now.
> 
> 3DES with 112-bits of security is being phased out as of January 1, 2024.

> When should we expect to see 2048-bit RSA, which also nominally has only
> 112-bits of security as does 2048-bit DSA become retired?


Ron wrote:
> I’m no expert when it comes to key strength, but I would expect a
> 2048-bit RSA key to last at least as long as 3DES, since both are
> considered to have 112 bits of security.

MDB: Note this is in NIST SP 800-131Ar2

URL: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf

Table 1.

    Three-key TDEA Encryption Deprecated through 2023
                              Disallowed after 2023

Ron wrote:
> The applies to DH keys as well. According to Wikipedia, RSA claimed
> back in 2003 that 2048-bit keys should be good until 2030, and even
> now the largest RSA key known to be cracked was a key with 829 bits.
> So, it seems like we’ve got another 5-10 years probably before we’d
> have to worry about phasing these keys out.
> 
> 
...elided...

MDB wrote:
> I might suggest Curve25519, as it is pretty fast and has many
> implementations.

Ron wrote:
> I’m definitely a big fan of curve25519/Ed25519, and indeed
> curve25519-sha256 is the most preferred key exchange algorithm in
> AsyncSSH right now. However, when it comes to choosing which algorithm
> to make a MUST, I figured that going with one of the plain DH
> algorithms might be less of a burden on implementers, as it’s much
> easier to change the key size than it would be to add ECC support to
> an implementation that doesn’t yet have it.


MDB wrote:
> That said, there are many who have been doing research which seems to
> show that ECC is easier to break with Quantum Crypto systems than FFC
> and are NOT interested in implementating ANY ECC algorithms.
> 
> I believe I have seen some text from implementers who have said they
> would NOT adopt ECC for their SSH implementations.

Ron wrote:
> That’s interesting - I hadn’t read that. I was aware of concerns about
> potential compromises in the nistp curves, but not specifically about
> Quantum attacks against ECC.

MDB:

I found the article. It was in Advances in Cryptology - ASIACRYPT 2017.

 Quantum Resource Estimates for Computing Elliptic Curve Discrete Logarithms
 by Martin Roetteler, Michael Naehrig, Krysta M. Svore, and Kristin Lauter
 November 2017, 24 Pages

URL: 

https://www.microsoft.com/en-us/research/wp-content/uploads/2017/09/1706.06752.pdf

It compares ECC with RSA (IFC) rather than really comparing against FFC DSA.

...elided...

MDB wrote:
> Perhaps we should opt to make diffie-hellman-group-exchange-sha256 a
> MUST? This allows implementors to put in whatever MODP groups they wish
> as long as q = (p-1)/2 ... so, a maximized q-ordered subgroup... though
> I o worry a bit about the way that the generator g is created perhaps
> not providing that g^q mod p == 1 is a will formed subgroup. When it is
> not a well-formed subgroup, then it will be leaking the first bit of the
> key value.
> 

Ron wrote:
> That’s an interesting thought. Are there “best practices” which could
> be followed in generating/validating these values that could avoid
> such a weakness?
> 
> For now, my implementation of the “group-exchange” algorithms has been
> to only let them select from a table of previously generated groups
> (basically the same group14-18 values that can be named directly). I
> haven’t looked into what it would take to construct new MODP groups.

It is not a difficult program to write, I just find that RFC 4419 is not
very good at given instructions. Basically, after you have a candidate
generator g, you need to ensure that g^q mod P == 1, then you have a
generator able to generate a proper q-orded subgroup. This is different
than RFC 4419 which just suggests forcing a congruence to 2 or 5 in
section 6.1. This method works about one quarter of the time. The rest
of the time the g value does NOT generate a proper q-ordered subgroup.

There are faster ways to generate p,q,g set of non-safe prime DH
parameters than the method outlined in RFC 4419, but then you won't
maximize the q = (p-1)/2 for the largest possible q-ordered subgroup...
and as SSH does only sends g,p, the client needs to assume it can
generate q if it needs to make any FIPS tests to make governments
happy... which includes doing a g^q mod p == 1 to ensure that any x
generated is a q-ordered subgroup.

...elided...
> They use ecdh-sha2-1.3.132.0.10 and so do I, following the guidance in
> RFC 5656 section 6.3 which states:

MDB: Ah.. Yes, I forgot about that detail. Thank you or the pointer.

Ron wrote:
> My rule on adding new curves (and algorithms in general) is that I
> want at least one other independent implementation of that support
> that I can do interoperability testing against before I’ll consider
> adding something. For now, I’m not aware of any SSH implementations
> that support any other curves, but if anyone knows of any, I’d love a
> pointer to them.

MDB: Me too.

> As for adding new named curves to this draft, I would recommend you
> focus only on implementations currently out there and not introduce
> anything new. I like the fact that this draft focuses on being a
> catalog of existing algorithms in actual use, and recommendations for
> which ones should be prioritized. If someone wanted to recommend new
> curves, I think that should probably be its own separate draft, and it
> can then decide whether to recommend using the OID format required by
> RFC 5656 or updating it to introduce additional non-OID algorithm
> names.

MDB: Fair enough.

	Be safe, stay healthy,
	-- Mark