Re: [saag] Yet another RFC-5114 attack

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sun, 23 October 2016 11:33 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24B0128B44; Sun, 23 Oct 2016 04:33:07 -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 F1Zq4lMGjhxY; Sun, 23 Oct 2016 04:33:02 -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 D46AE129514; Sun, 23 Oct 2016 04:33:01 -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=1477222381; x=1508758381; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RFzAzDOaa6r8i4fxreuHfuosL3oi+Qm0dSE/DjkxY50=; b=h8M4/hDgPTKf0sTmaM0eefQ91eezt6EznLS0GcjGcXiA5UcRcJVircHA mvVttM4RoVnhGw/EgdgZafA3hHKFDMyvKQ/rh+l86qiBXRhz0Hrpu5TnA ANfnYonL2v6bIzDqCgYCyzoMcQK2b4d2TApsjUp8SS1jMqjHwer0H/wvR 6yH01oPOUIlMPCbnBF89cITt3wO8UBysV0WQ6JoSfbAoAW+aU+bsYeDFG i0Xv8QPsXWaudNE3p1ZOPalw7WhmzozADQK1laCn1zdmg1pkNRSWIkJzj 4FRK9P9WT2gsNRY16jvzZvlRd41yXFa42FtX98+FkjUnFLS/rwSfZCxO8 A==;
X-IronPort-AV: E=Sophos;i="5.31,388,1473076800"; d="scan'208";a="111623691"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing
Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-tdc-b.UoA.auckland.ac.nz) ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 24 Oct 2016 00:32:57 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 24 Oct 2016 00:32:57 +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; Mon, 24 Oct 2016 00:32:57 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Paul Wouters <paul@nohats.ca>, "ipsec@ietf.org WG" <ipsec@ietf.org>, Security Area Advisory Group <saag@ietf.org>
Thread-Topic: [saag] Yet another RFC-5114 attack
Thread-Index: AQHSKUf706LEkw7PNk+MbYj2YFBVsaC17m90
Date: Sun, 23 Oct 2016 11:32:56 +0000
Message-ID: <1477222363928.11089@cs.auckland.ac.nz>
References: <alpine.LRH.2.20.1610180951020.18741@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.20.1610180951020.18741@bofh.nohats.ca>
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/saag/1DB4Ng40ZaJZHmbuZlWfiC5FIOU>
Subject: Re: [saag] Yet another RFC-5114 attack
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Oct 2016 11:33:08 -0000

And another one:

  http://eprint.iacr.org/2016/999.pdf

  Indiscreet Logs: Persistent Diffie-Hellman Backdoors in TLS

  Software implementations of discrete logarithm based cryptosystems over
  finite fields typically make the assumption that any domain parameters they
  are presented with are trustworthy, i.e., the parameters implement cyclic
  groups where the discrete logarithm problem is assumed to be hard. An
  informal and widespread justification for this seemingly exists that says
  validating parameters at run time is too computationally expensive relative
  to the perceived risk of a server sabotaging the privacy of its own
  connection. In this paper we explore this trust assumption and examine
  situations where it may not always be justified.

  We conducted an investigation of discrete logarithm domain parameters in use
  across the Internet and discovered evidence of a multitude of potentially
  backdoored moduli of unknown order in TLS and STARTTLS spanning numerous
  countries, organizations, and protocols. Although our disclosures resulted
  in a number of organizations taking down suspicious parameters, we argue the
  potential for TLS backdoors is systematic and will persist until either
  until better parameter hygiene is taken up by the community, or finite field
  based cryptography is eliminated altogether.

This problem at least:

  No mechanism is provided in TLS to communicate group order

is already fixed:

  https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/

Peter.