Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Fri, 27 August 2021 17:10 UTC

Return-Path: <prvs=4873d77cf9=uri@ll.mit.edu>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0F83A19AF for <tls@ietfa.amsl.com>; Fri, 27 Aug 2021 10:10:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.895
X-Spam-Level:
X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MAY_BE_FORGED=1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 QbacPNU6jA-B for <tls@ietfa.amsl.com>; Fri, 27 Aug 2021 10:09:58 -0700 (PDT)
Received: from MX2.LL.MIT.EDU (mx2.ll.mit.edu [129.55.12.51]) (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 61DC13A19AA for <tls@ietf.org>; Fri, 27 Aug 2021 10:09:58 -0700 (PDT)
Received: from LLE2K16-HYBRD01.mitll.ad.local (lle2k16-hybrid01.llan.ll.mit.edu [172.25.5.112] (may be forged)) by MX2.LL.MIT.EDU (8.16.1.2/8.16.1.2) with ESMTPS id 17RH9tir159066 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <tls@ietf.org>; Fri, 27 Aug 2021 10:09:55 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=w90pe1bn5HUNaLYVXLSZ1HFH3ljD9PIdKuscgmtK+Lz7mAzdJtIeStfAoPzVCLZuxL/vxWJ1zW29RfZGk4cz23xzmLZk71/Ia84ixOmVXgp9+kjDZNtNifwwHAmy3aoRNeWetZhsb/CHrHNK0HrbnspNoOX4gWl9WeqavBoUXB9MrEaPHmUxnoRtpa/SStlrjLyib4NvGkX400NcxzfTG2MvTVI37mgDh7HaUIRn5Ec1saOdCGgqaPBaEy0JgTnHSuMTg4OlZkxrdiQsGk0J5hxUPdfcxhgwfa5W6T1QtAv8/P3yZKq5vDlKER7Qijn9PSKi455FEjs4PHZCdpQnvw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H/NV8Exd7awa6uZtlxvIrVaBiRV2WhF8U4TTf4bPgic=; b=ptc68PAyWEryfjTSDYNrMXhN1t48n7fa0PQYXZdTPt+3bcuZFvbLC84cK+QK6HbBEOrVmG2BQxu7jWQ3lTqU2eTmqGIq3qHSrqMUXLxCq9lP1APrD0vyMi72Ncnwk91WqoErG3JbdGHtF84Pge1wM4CnaP5sX/uhZ8CBffiik0ahbFlt2C7Cig8+SWiv7rlpzlGRGGdDkxjfaSIUAuv4emzzGcPWZWaxInj9tg5MepmX9xHRtn9Eip+IjuirQJvGAmHCPSjYtX/301Br003fcmL/42O+N5bKUj1PhQvSKZDjf0uu3QuDY3Tj/UTiq1GOdf/YSTVFlkBdSuvJ9sX9IA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS
Thread-Index: AQHXhMPxpzrCMsaNt0Kem/sQDBKbl6txjJmA///1ygCABYc1gIAAx+iAgAjU1YCABjHNgIAAaP2A///8/wCAAEjSAIAAHzMAgAAU7QD//8ULgA==
Date: Fri, 27 Aug 2021 17:09:52 +0000
Message-ID: <B572B6ED-A44D-4E5D-83AC-467F71A33FE5@ll.mit.edu>
References: <CAOgPGoC4C0bWz0h0iyzGzMPEoDKAPv4euoOkmS+6Uuxncux4Zg@mail.gmail.com> <cc9c9d9f-d6b1-3b93-1231-a9a9c34a7fcd@gmail.com> <67533325-2983-47B7-871C-D90799D09532@ll.mit.edu> <CAOgPGoDAvnFic3VmEsge3i8C2FEfWp74ac_ievtfNo=MQB+C8g@mail.gmail.com> <C8E91D9B-2326-4AAF-9952-69481081E337@ll.mit.edu> <BD109A95-129A-4995-AFCA-FEF10DBD6440@icloud.com> <CAOgPGoBMhhsTupXuWF__zkLuy-4qQhha_Kp1_+ToZrNoaFUsgQ@mail.gmail.com> <13b9e674-9e0b-46aa-b5d6-49798c310d85@www.fastmail.com> <5D5FB49A-7D18-4EC9-B572-BD860479CD5E@ll.mit.edu> <bc91502a-471e-484e-ae5f-d843b703edd6@www.fastmail.com> <64c6ca0a-b3cf-cbdf-c1be-7cc4cc050a52@gmail.com> <0ba2ed9a-3128-4956-bd9d-2b961cbcb6d0@www.fastmail.com>
In-Reply-To: <0ba2ed9a-3128-4956-bd9d-2b961cbcb6d0@www.fastmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.52.21080801
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ll.mit.edu;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0e3bbb3f-8957-45df-ad98-08d9697d7c14
x-ms-traffictypediagnostic: BN1P110MB0195:
x-microsoft-antispam-prvs: <BN1P110MB0195BD6BB2913761D3C766B490C89@BN1P110MB0195.NAMP110.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: cbQmiZJqZkfDHsWdHiU9lpFvpNzIf28n2eLHZx4/fBzqXgKwMTc30BeRy245AtwTY3ccdU+RdWbwQxHyGOoPgd+bEBtcGl+C9lcQe69PHIZpHAV3ff2j7XWkVHd8GWJXsI/BHK5S0Ypez94r5Vafc6pXRA/m3sWkHZZlVCRcfKSvWgMpssf2K5k41sID5tbRZSwMj62QmFPhAVfpRG2lhgw/ZYfRQ9K3OpnLvoHDUDrPFeJ3YX9LKjohYdggK9gHj7gpANWIc9/mvzwkrBfhkY1ajkMUJKdpbuib3StJnix2NRmCubU5ZvALl9szs9nhUdEknUa2A0qq47rK6ZYhhouxOsIDnKe2hXdaaXDS7jD3D1/q67tUDVwtVQa7z5OJ82FPwCd9fJndhAH8vZgmYdtABhoWWYoU/Qb5xDRAjgFvuetGR6GpvDIBFissypgRz7E5u7Nl23Z3svziCU8ONWgvyJmnBP74vm/2QbgB14woqB8DK+YPEWs/Iy02IdFsNBiR4VVoJpRsNvmGFtOwzYewSO6R1zS9+ofgf3g020OWoMGWw9UO+L3esd+ac7LkH+gDFORgp92F2wELjiidwme6YqoCjtz/vguzeKQPMStGfVnjjIcgXbZQ+iSLxSM/FAar0qNRfC8RlEfIcgaM4yiiyYy/QpDiordyoqa9qEvprKNpcTgWosZb0tKe9pj2SzvBpR7NxJdJQgjNfzjxlPFUfShJ5uL1I7XQglRFJ9YfiuiZt0Oddi8zwiS96Lns
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN1P110MB0706.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(376002)(366004)(39850400004)(396003)(38100700002)(186003)(166002)(86362001)(66946007)(122000001)(66616009)(66446008)(6486002)(6506007)(2616005)(2906002)(75432002)(53546011)(83380400001)(38070700005)(33656002)(5660300002)(316002)(66556008)(26005)(76116006)(71200400001)(99936003)(966005)(6512007)(8936002)(8676002)(6916009)(64756008)(66476007)(478600001)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: hTEU2TQhPC1uO4aeZ2wVuyAbm+Q+ee4rl1wzCm/V8X6ImItPEanICrPquwIzgtaH2xEU6F0UOT9tnzhCC1VYDRwm5u2R/CnxQlk0VVy4b96jXD79129dYNZBv4YNA7j76pZKKVvLWuLxovSZE4lW9yQl9zIEM0gHvWyCY8gAi1dOGZlCD0vPzEySM9NsI3KnES2pb5kziqvwdByoTaYTOiKubQequSPomLSol9+zDxGeRslmuZ6/igwlvYPHEEkuE2hiuhRLqOP/K0Rc44fW8Yy2O6IQVln+iYiz9mL25yQxSPYlE29LQa+5JXJp4OEYfvxUFSYSffcaXXut8YWHFoUOtD/MHsp7+6My8gf7p6kOJjFIUwfEnA8TrtunJU0DiloYTE7LIOn92Cbl5hldATNTaAB7l23rKxJpYAkOk/HNpjXC1x99BbhnEFhDnV5jp79laoEUKu7l4M8mSrfd5RNgEOv5sFf1aAlcqQqwxH9P0Yem9CeeaLvHv+gnKlp1K9akVgqBrnqOiUt/wagDgCR/jEgoQd3h1q8P8y7OHdwK4vV7I77hKX4AhSSK/7euhO/Tn/RAo02qJnnFuqWOYLTlO+eYJkCfwARRZfw2ruRYUGZBIQUxrzyrPym2LVP9deqqD5gibxBnmj21lHKlI5qRpXSog6wYlLgq5YDifDA3fRrSmXHbazEOBKeSnvx06P3ZkKkFEECUzJ9Dq0Do0Q==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3712914591_1141991355"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN1P110MB0706.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 0e3bbb3f-8957-45df-ad98-08d9697d7c14
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2021 17:09:52.1894 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1P110MB0195
X-OriginatorOrg: ll.mit.edu
X-Proofpoint-GUID: STW3MKhecI-S1VbuCTjpzGuOIbyJDMYV
X-Proofpoint-ORIG-GUID: STW3MKhecI-S1VbuCTjpzGuOIbyJDMYV
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-27_05:2021-08-27, 2021-08-27 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 adultscore=0 malwarescore=0 spamscore=0 phishscore=0 mlxscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108270103
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/B_pQSyAYTKI397c7W2SUMOClvkg>
Subject: Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Aug 2021 17:10:05 -0000

A closer look at your referenced CVEs suggests these can be classified as (i) lack of checking for improperly generated DH groups; (ii) exploiting overflow/underflow/carry bugs. To me, nothing seems to be new here and more likely a failure of implementers to heed to results and advice predating the CVEs by years (and sometimes decades) or in QA processes. E.g., with respect to (i), one had not gotten oneself into trouble if one had actually bothered to implement domain parameter checks. In the literature of implementation attacks, OpenSSL has proven to be an excellent "implementation security flaw paper generator".

 

I have yet to see evidence that ephemeral-static ECDH would be inherently insecure.

 

If a consistent history of directly linked vulnerabilities across major implementations doesn't show something is unsafe, I don't think there is progress to be made in the discussion. Blaming the implementers is not particularly interesting to me.

 

First, is this the only mode that has “directly linked vulnerabilities”? Second, cutting corners (e.g., for performance sake) by omitting domain parameters check, or not taking care of over/underflow, and such, cannot be considered a “protocol or algorithm fault”. Blame who you want, but the facts are here.

 

 

Anyway, I don't have an opinion on SHOULD NOT vs MUST NOT, as long as it leads to Recommended: N in the registry.

 

“MUST NOT”     => “if you do that, you’re not compliant, period”.

“SHOULD NOT” => “don’t do that, unless you have very good reasons, and can explain to your customers why it’s really OK in that particular case”.

 

Correct, both should lead to “Not Recommended”.

 

 

On 2021-08-27 9:34 a.m., Filippo Valsorda wrote:

[snip] 

 

This is empirically disproved by a number of vulnerabilities that are exploitable (or near-misses for other reasons) only in ephemeral-static mode, such as CVE-2016-0701, CVE-2016-7055, CVE-2017-3732, CVE-2017-3736, CVE-2017-3738, CVE-2019-1551 just in the past 5 years in OpenSSL, and CVE-2017-8932 and CVE-2021-3114 in Go. https://eprint.iacr.org/2011/633 gives a good explanation of how these attacks work, and you might find https://i.blackhat.com/us-18/Wed-August-8/us-18-Valsorda-Squeezing-A-Key-Through-A-Carry-Bit-wp.pdf interesting as well.

OpenSSL:

CVE-2016-0701: improper generation of Diffie-Hellman group

The DH_check_pub_key function in crypto/dh/dh_check.c in OpenSSL 1.0.2 before 1.0.2f does not ensure that prime numbers are appropriate for Diffie-Hellman (DH) key exchange, which makes it easier for remote attackers to discover a private DH exponent by making multiple handshakes with a peer that chose an inappropriate number, as demonstrated by a number in an X9.42 file.

CVE-2016-7055: carry-propagation bug

There is a carry propagating bug in the Broadwell-specific Montgomery multiplication procedure in OpenSSL 1.0.2 and 1.1.0 before 1.1.0c that handles input lengths divisible by, but longer than 256 bits. Analysis suggests that attacks against RSA, DSA and DH private keys are impossible. This is because the subroutine in question is not used in operations with the private key itself and an input of the attacker's direct choice. Otherwise the bug can manifest itself as transient authentication and key negotiation failures or reproducible erroneous outcome of public-key operations with specially crafted input. Among EC algorithms only Brainpool P-512 curves are affected and one presumably can attack ECDH key negotiation. Impact was not analyzed in detail, because pre-requisites for attack are considered unlikely. Namely multiple clients have to choose the curve in question and the server has to share the private key among them, neither of which is default behaviour. Even then only clients that chose the curve will be affected.

CVE-2017-3732: carry-propagation bug

There is a carry propagating bug in the x86_64 Montgomery squaring procedure in OpenSSL 1.0.2 before 1.0.2k and 1.1.0 before 1.1.0d. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. For example this can occur by default in OpenSSL DHE based SSL/TLS ciphersuites. Note: This issue is very similar to CVE-2015-3193 but must be treated as a separate problem.

CVE-2017-3736: carry-propagation bug

There is a carry propagating bug in the x86_64 Montgomery squaring procedure in OpenSSL before 1.0.2m and 1.1.0 before 1.1.0g. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. This only affects processors that support the BMI1, BMI2 and ADX extensions like Intel Broadwell (5th generation) and later or AMD Ryzen.

CVE-2017-3738: overflow bug

There is an overflow bug in the AVX2 Montgomery multiplication procedure used in exponentiation with 1024-bit moduli. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH1024 are considered just feasible, because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be significant. However, for an attack on TLS to be meaningful, the server would have to share the DH1024 private key among multiple clients, which is no longer an option since CVE-2016-0701. This only affects processors that support the AVX2 but not ADX extensions like Intel Haswell (4th generation). Note: The impact from this issue is similar to CVE-2017-3736, CVE-2017-3732 and CVE-2015-3193. OpenSSL version 1.0.2-1.0.2m and 1.1.0-1.1.0g are affected. Fixed in OpenSSL 1.0.2n. Due to the low severity of this issue we are not issuing a new release of OpenSSL 1.1.0 at this time. The fix will be included in OpenSSL 1.1.0h when it becomes available. The fix is also available in commit e502cc86d in the OpenSSL git repository.

CVE-2019-1551: overflow bug

There is an overflow bug in the x64_64 Montgomery squaring procedure used in exponentiation with 512-bit moduli. No EC algorithms are affected. Analysis suggests that attacks against 2-prime RSA1024, 3-prime RSA1536, and DSA1024 as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH512 are considered just feasible. However, for an attack the target would have to re-use the DH512 private key, which is not recommended anyway. Also applications directly using the low level API BN_mod_exp may be affected if they use BN_FLG_CONSTTIME. Fixed in OpenSSL 1.1.1e (Affected 1.1.1-1.1.1d). Fixed in OpenSSL 1.0.2u (Affected 1.0.2-1.0.2t).

Go:

CVE-2017-8932: arithmetic bug

A bug in the standard library ScalarMult implementation of curve P-256 for amd64 architectures in Go before 1.7.6 and 1.8.x before 1.8.2 causes incorrect results to be generated for specific input points. An adaptive attack can be mounted to progressively extract the scalar input to ScalarMult by submitting crafted points and observing failures to the derive correct output. This leads to a full key recovery attack against static ECDH, as used in popular JWT libraries.

CVE-2021-3114: underflow bug

In Go before 1.14.14 and 1.15.x before 1.15.7, crypto/elliptic/p224.go can generate incorrect outputs, related to an underflow of the lowest limb during the final complete reduction in the P-224 field.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
 
 
-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867