Re: [TLS] DH security issue in TLS

"Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> Tue, 03 December 2019 23:03 UTC

Return-Path: <sfluhrer@cisco.com>
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 31FAC120096 for <tls@ietfa.amsl.com>; Tue, 3 Dec 2019 15:03:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=GyGeYYPc; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=wdJcatye
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 eujMPBWdorVx for <tls@ietfa.amsl.com>; Tue, 3 Dec 2019 15:03:24 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDFF1120045 for <tls@ietf.org>; Tue, 3 Dec 2019 15:03:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13286; q=dns/txt; s=iport; t=1575414204; x=1576623804; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=shNVCVeNFYdMiOZ0yYKYJZ1NZI0sxQDiRGGh5FHHqDM=; b=GyGeYYPcg0sH/XKgrx/rtTztpAzUa5Kid0n2MEeKzJrIpQgvPWSqrVf8 DfqvWpSYa7B56KLRn0lNq27w/mtagzqXJuO3FGR0UH72CPpmuylXV98zJ PBuA0gW5ujlpOKN85q3HgVMDR4eWERWNCDKVXbRGpCa8J0wuytU+zA2ru Q=;
IronPort-PHdr: =?us-ascii?q?9a23=3AAmKnFhEWb894kXJFyfnY751GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeXkazE6BslYfFRk5Hq8d0NSHZW2ag=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BjAAAf6eZd/5NdJa1lGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBawUBAQELAYEbL1AFbFggBAsqCoQhg0YDinlOghGTIoR?= =?us-ascii?q?igS6BJANUCQEBAQwBAR8OAgEBhEACF4F2JDUIDgIDDQEBBAEBAQIBBQRthTc?= =?us-ascii?q?MhVIBAQEBAxIRChMBASsNDwIBCBEEAQErAgICMB0IAgQBEggagwGBeU0DLgE?= =?us-ascii?q?CDKZpAoE4iGB1gTKCfgEBBYULGIIXAwaBNgGMFRqBQT+BWIIXNT6CZAEBA4F?= =?us-ascii?q?iK4JjMoIskB6FTJhdCoIuhx6OVpokjkqIPpFfAgQCBAUCDgEBBYFTATeBWHA?= =?us-ascii?q?VgydQERSMZoNzhRSFP3SBKI9HAYEPAQE?=
X-IronPort-AV: E=Sophos;i="5.69,275,1571702400"; d="scan'208,217";a="677255781"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Dec 2019 23:03:22 +0000
Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id xB3N3M0Q008399 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Dec 2019 23:03:23 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 3 Dec 2019 17:03:22 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 3 Dec 2019 17:03:21 -0600
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 3 Dec 2019 17:03:21 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZyN2Z63DC/fpypIAW7Q3Ow433vzaLhuO0MqgGzCQ96LZAl7zVMFR5VBAOfUxCyOxRuaGG3uLyyNBewX4Pb/1lW/D0UbUrF8ePkYmoewiyAP0qyP0n9hhQXujc1Onoamd8Nw7y74K+tVlKgZ8wBZj7Y275pcR3SOpRLZTm/ZLF5ruRhUOC92HqfRDuNpErQmlRr65GbTYnMD5ZRp/R9/L8VjebOjhNDt2mT+9+zqRaWsxeSEJkcEFIPt6wGkMZWtp1tVO3LaDwQ2uG8uzAHQS3LedikNnNY9hzRtJ1cFrI8dLEdltrEwDZM2qB3Nz9dYIvrS7nG0HwCMkhVJhCcWx8g==
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=shNVCVeNFYdMiOZ0yYKYJZ1NZI0sxQDiRGGh5FHHqDM=; b=ag49Xt0Tg2dse/3YEGq0y/H7Srp6hW6P5CaGMWzSO4AA4AQ0kfr24IjsVoOXKeL00WR11nleouo4sDSS0p8sASp02P4KZP8hBdv2q1+rOcl2/XE/vFC2Av0jl9quW/v+GM2o++IcZ4SvWN+Bbxe2UvxdvpYmEXDqCPqtmhwWdutnjEASYrDcnoIiuWN8879LcIj/xFZddjh+mkFQZJMqQEXHJ0x/XPA1SDGCAAmbABkEqeOuebGf+rlgaWSarQ7eZW33Qz3L8gh22Of9juLb4ty4bkcbbsEnIXe6TFdRdnC5G/9rseaN4UYTtF744gzMBiduVAivhV2bnJ6jAkNy+w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=shNVCVeNFYdMiOZ0yYKYJZ1NZI0sxQDiRGGh5FHHqDM=; b=wdJcatyeWIsUntEd85DPqlL5C7bbxFhOEyWIWXEpc+hBaZsELcB70864ofB/7jmbo8om2Gxxyr7SLjkSbYtcvLgU9PeALbB95OTeWuOU1PPlPSFE0d72rq3hFuoKpbfk5OaVJG5JCCXq2n6hEwfth1ZYSdPnaRzxmOAzH2qj3QM=
Received: from BN8PR11MB3666.namprd11.prod.outlook.com (20.178.221.19) by BN8PR11MB3684.namprd11.prod.outlook.com (20.178.219.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.17; Tue, 3 Dec 2019 23:03:20 +0000
Received: from BN8PR11MB3666.namprd11.prod.outlook.com ([fe80::815c:974a:5eab:868b]) by BN8PR11MB3666.namprd11.prod.outlook.com ([fe80::815c:974a:5eab:868b%7]) with mapi id 15.20.2495.014; Tue, 3 Dec 2019 23:03:20 +0000
From: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
To: Pascal Urien <pascal.urien@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] DH security issue in TLS
Thread-Index: AQHVqieAYle6LbLNokyo/QnWl+zL16eo/MqQ
Date: Tue, 3 Dec 2019 23:03:20 +0000
Message-ID: <BN8PR11MB36661739568DB959F7C9D2C4C1420@BN8PR11MB3666.namprd11.prod.outlook.com>
References: <CAEQGKXQAd=j_UyBEQPv7frmcDn_=DoBbvEccCkLPr4odSDcqQw@mail.gmail.com>
In-Reply-To: <CAEQGKXQAd=j_UyBEQPv7frmcDn_=DoBbvEccCkLPr4odSDcqQw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sfluhrer@cisco.com;
x-originating-ip: [173.38.117.71]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0494c7c5-3656-458c-f8c4-08d77844fde1
x-ms-traffictypediagnostic: BN8PR11MB3684:
x-microsoft-antispam-prvs: <BN8PR11MB3684CE751E8450F2245C28A0C1420@BN8PR11MB3684.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02408926C4
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(366004)(346002)(376002)(39860400002)(199004)(189003)(54094003)(76116006)(64756008)(81166006)(66446008)(8676002)(71200400001)(71190400001)(33656002)(66946007)(186003)(2501003)(5660300002)(966005)(81156014)(9686003)(478600001)(8936002)(6436002)(66476007)(25786009)(6306002)(54896002)(66556008)(55016002)(15650500001)(86362001)(6246003)(74316002)(236005)(2420400007)(7736002)(14454004)(76176011)(26005)(606006)(11346002)(446003)(7696005)(3846002)(7110500001)(229853002)(2906002)(99286004)(110136005)(256004)(102836004)(53546011)(6116002)(52536014)(6506007)(790700001)(14444005)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3684; H:BN8PR11MB3666.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: z3ElNaNaeQ0Dbp5nP0qHqDMrDlH6pnf9esuOfTljwqTC455BA85mSZOqmpIWHSuwGZR/EAKI/CgoWnNRxu6JSmmQM4lGc+rhr/hC8et430ITQyxbaFEPw1b64iyILospbtghUOvQx3yrSbxZ2NJ3gvO39UMvz2zhqpxsE9t5fs9tvZZng1+ouyGf+gs2k2aLwQ1U42CVechTypIf5zXRClVWy7liMb5MgMGkDN6X+sTMuFclBxaMtsFXaqrFRfscmTj9zXvq8jIAAY16MG7Eq3ORBIvdkD9YWCV4qdffdncfE3DIoWHwklh+WZ1QbC9jeVZPcAGEOeFzE7nBf0KjinQiUUWgnXqqbqqilY/wVYOdSNWm4KagM3ZYXy2hSZm+lV77oQdtrKaub/FZVfvDHRtt3RwDf3UWoT5PSk4UlfIqmA4b7amih3u6L9bB6fp00v2H/uYQ1LS8Q9e50hFSPw6YleXuvL3PWKrm5sy6jbk=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BN8PR11MB36661739568DB959F7C9D2C4C1420BN8PR11MB3666namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0494c7c5-3656-458c-f8c4-08d77844fde1
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2019 23:03:20.6220 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: PQxHjbSfL9D6R3Vr/7VbWeY/VAg1hcFyh2rNlPheBMKMy2B6TQQvGgBaWHMT5dwvorhk8gH03q22hpkwy6jwgg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3684
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.25, xch-aln-015.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XcCzzFxTr8TjPX5m7-68fX_xX0c>
Subject: Re: [TLS] DH security issue 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: Tue, 03 Dec 2019 23:03:27 -0000

See SRF

From: TLS <tls-bounces@ietf.org> On Behalf Of Pascal Urien
Sent: Tuesday, December 03, 2019 5:16 PM
To: tls@ietf.org
Subject: [TLS] DH security issue in TLS

I wonder if g**x , with x =(1-p)/2 is checked in current TLS 1.2 implementation ?

In RFC https://tools.ietf.org/html/rfc7919
"Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)"

"Traditional finite field Diffie-Hellman has each peer choose their secret exponent from the range [2, p-2].
Using exponentiation by squaring, this means each peer must do roughly 2*log_2(p) multiplications,
twice (once for the generator and once for the peer's public key)."

Not True !!!
Even for p= safe prime (i.e.. Sophie Germain prime, p=2*q+1, with p & q prime number) secret exponent x= (p-1)/2 is a security issue since :

g**xy = 1       with y an even integer
g**xy = g**x   for y an odd integer

SRF: actually, g**xy  = 1 in both cases, as g**x = 1 (for the g, p values specified in RFC7919); this is easily seen as all listed p values are safe primes, and in all cases, g=2 and p=7 mod 8.

In any case, why would that be a security issue?  If both sides are honest (and select their x, y values honestly), the probability of one of them selecting (p-1)/2 as their private value is negligible (even if our selection logic allowed that as a possible value – it generally doesn’t).  If we have two honest parties with an adversary replacing one of the side’s key share with g**(p-1)/2, well, the protocol transmits signatures of the transcript, and so that’ll be detected. If you have an honest side negotiating with a dishonest one, well, the dishonest one could select (p-1)/2 as its private value – however, they could also run the protocol honestly (and learn the shared secret and the symmetric keys, which are usually the target), and there’s nothing the protocol can do about that.

Now, if an honest party reused their private values for multiple exchanges, a similar observation would allow an adversary to obtain a single bit of the private value.  He would do that by performing an exchange with the honest party mostly honestly, selecting a value x as his private value, but instead of transmitting g**x as his key share, he would transmit -g**x.  Then, the shared value that the honest party would derive is:

  g**xy  with y an even integer
  -g**xy  with y an odd integer

The adversary can compute both these values, and determine which is being used later in the protocol.

So, the adversary can learn a single bit of the private value (which doesn’t translate to him learning any bit of the shared secret, much less the symmetric keys) – however, he cannot leverage this to learn anything else of the private key.  I do not believe that a single bit is worth worrying about.  And, again, if we generate a fresh DH private value for every exchange (which we encourage people to do for PFS), even that single bit doesn’t apply to any other exchange.



If p is not a safe prime (like in RFC 5114) other issues occur....


Pascal