Re: [Cfrg] Security proofs v DH backdoors

Hanno Böck <hanno@hboeck.de> Tue, 25 October 2016 13:42 UTC

Return-Path: <hanno@hboeck.de>
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 3EF7E129493 for <cfrg@ietfa.amsl.com>; Tue, 25 Oct 2016 06:42:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 I4rgZQa9GOuW for <cfrg@ietfa.amsl.com>; Tue, 25 Oct 2016 06:42:06 -0700 (PDT)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADB02129427 for <cfrg@irtf.org>; Tue, 25 Oct 2016 06:41:54 -0700 (PDT)
Received: from pc1 ([2001:2012:115:3d00:8e6b:8908:764f:9343]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Tue, 25 Oct 2016 15:41:52 +0200 id 0000000000000087.00000000580F6120.00004123
Date: Tue, 25 Oct 2016 15:41:49 +0200
From: Hanno Böck <hanno@hboeck.de>
To: cfrg@irtf.org
Message-ID: <20161025154149.62f79f45@pc1>
In-Reply-To: <20161025131014.5709905.2866.6563@blackberry.com>
References: <20161025131014.5709905.2866.6563@blackberry.com>
X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-16675-1477402912-0001-2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/omZvvBikuwKRWzDVJkeynw-TWPI>
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: Tue, 25 Oct 2016 13:42:10 -0000

On Tue, 25 Oct 2016 13:10:16 +0000
Dan Brown <danibrown@blackberry.com> wrote:

> How do the 3 recent IACR eprints on FFDH backdoors‎ reconcile with
> past security proofs for TLS, SSH, etc?
> 
> Some guesses: (1) the attacks are outside the security definitions
> (=> attacks not so important?), (2) the proofs assume strong FFDH
> groups plus validation, etc.

I think the general assumption is that a server is non-malicious and
sends good parameters.
However there was one example of an attack discovered by a formal
analysis of the TLS protocol where impersonating a user with a client
certificate to another server involved using bad DH parameters (Triple
Handshake [1]). That seems a bit like a special cornercase though.


I wonder how the scenario of malicious parameters can be formally
stated and what the expectations would be. Somewhat related is that the
whole NUMS idea is still unsettled, given that we had a bunch of cases
where the designers of some algorithm tried to make something
nonsuspicious looking, but it was later still criticized for being
suspicious (e.g. NIST curves, Brainpool vs. Bada55).


[1] https://mitls.org/pages/attacks/3SHAKE

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42