Re: [TLS] Static DH timing attack

Karthik Bhargavan <karthikeyan.bhargavan@inria.fr> Wed, 09 September 2020 15:19 UTC

Return-Path: <karthikeyan.bhargavan@inria.fr>
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 7A9183A0D3B for <tls@ietfa.amsl.com>; Wed, 9 Sep 2020 08:19:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=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
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 tSlDFzpWsZ2x for <tls@ietfa.amsl.com>; Wed, 9 Sep 2020 08:19:18 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 A34F03A0CB4 for <tls@ietf.org>; Wed, 9 Sep 2020 08:19:17 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.76,359,1592863200"; d="scan'208";a="358517990"
Received: from 89-156-101-160.rev.numericable.fr (HELO [192.168.0.20]) ([89.156.101.160]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Sep 2020 17:19:15 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr>
In-Reply-To: <5595BB40-3AFD-4327-B7B7-5E63FFC594DD@akamai.com>
Date: Wed, 09 Sep 2020 17:19:13 +0200
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2EC5AE8C-F9A3-4C86-B52C-4C1BD2AD8BEB@inria.fr>
References: <5595BB40-3AFD-4327-B7B7-5E63FFC594DD@akamai.com>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MBE_9dncmuhXfW100q0XwmR1_2I>
Subject: Re: [TLS] Static DH timing attack
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: Wed, 09 Sep 2020 15:19:19 -0000

Hi Rich,

I think static DH, or reusing ephemerals, has always been a weak point of TLS implementations: e.g. if you don’t validate the peer’s public value, you may leak your (reusable) private value. In principle, if implemented correctly, static DH can be ok if you don’t care about forward secrecy, but TLS 1.2 also did this weird thing of truncating the result of DH to strip leading zeroes, which leads to this attack. Retiring static DH and forbidding ephemeral key reuse in TLS 1.2 seems like the safest way forward.

Note that TLS 1.3 does not truncate the result of DH, and neither does draft-green-tls-static-dh-in-tls13, and both (should) ask for peer keys to be validated, so these issues should not apply to TLS 1.3 implementations (unless they are buggy.)

-Karthik




> On 9 Sep 2020, at 17:04, Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org> wrote:
> 
> https://raccoon-attack.com/
>  
> Do we need a short RFC saying “do not use static DH” ?
>  
> I am probably not the only one thinking fondly of draft-green-tls-static-dh-in-tls13 now.
>  
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls