Re: [Cfrg] Security proofs v DH backdoors

Peter Gutmann <pgut001@cs.auckland.ac.nz> Fri, 28 October 2016 09:36 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F5B1298C4 for <cfrg@ietfa.amsl.com>; Fri, 28 Oct 2016 02:36:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.631
X-Spam-Level:
X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 XrW5zczn9BQe for <cfrg@ietfa.amsl.com>; Fri, 28 Oct 2016 02:36:11 -0700 (PDT)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F3A12943B for <cfrg@irtf.org>; Fri, 28 Oct 2016 02:36:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1477647370; x=1509183370; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tvMIc7L9P1OGdQrzvf3fgPG/8T5ui40fJgg3/sEqt8A=; b=X+hsY0oKzNV5KVKZpUmSP2WMUS+TaPubac0VLMd4DXrw6n6J2gYv3Z1C yDhAe1bvXK5TC2/KAA/JCrpYVL47Z7EPu/jBzGbGgwVyDPn2syvqn9vL7 S+KuzSXBfkELSpSWjR6U1XedlS0q5zpa74CB/briCgSHJEPGIIe7V0NKr pDR/OoyqvEN1i4bCfbOM0cjZlbfH9P6AIVtsee/HuaNMR6q2KFqvejNXc BUe+rmVNtD2tn8FMfGhoQ39uao2pItrqTon1TYn9p2hlfPZzIUTv+23JB ZWnwH1sIYe5YRggdVz9YQqt1oJPVCXoK2vj1Gbo0AVLYV6uDxgcUD0FZ9 Q==;
X-IronPort-AV: E=Sophos;i="5.31,557,1473076800"; d="scan'208";a="112466174"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing
Received: from uxcn13-ogg-a.uoa.auckland.ac.nz ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 28 Oct 2016 22:36:07 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 28 Oct 2016 22:36:07 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Fri, 28 Oct 2016 22:36:07 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: =?iso-8859-1?Q?Hanno_B=F6ck?= <hanno@hboeck.de>, Dan Brown <danibrown@blackberry.com>
Thread-Topic: [Cfrg] Security proofs v DH backdoors
Thread-Index: AQHSMEAWZy2e+SPalEyp/G+CJ2BAv6C9nFXG
Date: Fri, 28 Oct 2016 09:36:07 +0000
Message-ID: <1477647359860.49982@cs.auckland.ac.nz>
References: <20161025131014.5709905.2866.6563@blackberry.com> <20161025133016.GA9081@LK-Perkele-V2.elisa-laajakaista.fi> <1477456366629.49872@cs.auckland.ac.nz> <44595.1477524032@eng-mail01.juniper.net> <20161027103214.5709905.11728.6650@blackberry.com>, <20161027125120.4d260334@pc1>
In-Reply-To: <20161027125120.4d260334@pc1>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/UQeCDq4XqNE7OlFlZeRY1QepSFk>
Cc: CFRG <cfrg@irtf.org>
Subject: Re: [Cfrg] Security proofs v DH backdoors
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Oct 2016 09:36:12 -0000

Hanno Böck <hanno@hboeck.de> writes:

>This line of debate and all the recently released papers show one very
>concerning thing: We haven't learned how to use Diffie Hellman properly

Well, we have, what it really shows is that there are still implementations
around that use it badly.  As there are for almost everything.

>But why should we have this discussion when we already know DH is on its way
>out? 

It's going to be around for a long, long time, if not forever, for three
reasons.  Firstly, your assumption, which I've heard from others as well,
seems to be based on the browser/web server worldview where you can roll out
an update any time you like to make the server/client do whatever you want it
to.  However, if you look at real-world surveys of TLS traffic, the most
common TLS mode is still 1.0, dating from 1999.  This means that for general
web traffic, not just what Chrome, Firefox, and Edge do, there's at least a
15-year latency for deployment.  In terms of industry bodies, groups like the
PCI council are planning to move to TLS 1.1, from ten years ago, by 2018.
There's no indication of when they'll start looking at TLS 1.2.  Other
industry bodies in the SCADA/embedded space are roughly the same, there's a
gradual move from TLS 1.0 to TLS 1.1 with some mutterings about 1.2 in some
places.

Secondly, DH's replacement, the ECC algorithms, are an absolute non-starter in
any kind of harsh environment.  They're the most brittle crypto you can
possibly deploy, any fault of any kind inevitably ends up leaking the private
key.  I know several industries who, despite its great trendiness, won't touch
the ECC stuff because it's just too brittle to safely use.

Finally, specifically for the Bernstein protocol suite [0] if that's what
you're thinking of for supplanting DH, it's easy enough for someone like
Google to decree that from now on we all have to use X, but many industries
are heavily constrained and regulated and can't just adopt whatever new
algorithm comes along.  Also, hardware support for crypto is almost
universally AES, SHA-1, SHA-2, and sometimes (rarely) some bignum stuff.
You're not going to see any move to TLS 1.3/2.0/whatever-it'll-be-called
outside the web server/client space any time soon there, if ever.

>Chrome already decided to disable it, others will follow. 

That's because Google can decree that from now on we're all going do be doing
what Google wants.  That doesn't work in other industries.

Peter.

[0] No disrespect to Dan et al intended, I'm just using it as a collective
    noun for 25519, 448, ChaCha, Poly1305, etc because I don't know of any
    other collective term for them.