Re: [TLS] Negotiated Discrete Log DHE revision [was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3]

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 09 April 2014 00:53 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419471A075A for <tls@ietfa.amsl.com>; Tue, 8 Apr 2014 17:53:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 A5O7n9nL4t3f for <tls@ietfa.amsl.com>; Tue, 8 Apr 2014 17:53:49 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5211A0192 for <tls@ietf.org>; Tue, 8 Apr 2014 17:53:49 -0700 (PDT)
Received: from [192.168.13.159] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id E14E2F984; Tue, 8 Apr 2014 20:53:46 -0400 (EDT)
Message-ID: <53449A18.9000803@fifthhorseman.net>
Date: Tue, 08 Apr 2014 20:53:44 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0
MIME-Version: 1.0
To: Michael D'Errico <mike-list@pobox.com>
References: <AD51D38F-2CFE-4277-854D-C0E56292A336@cisco.com> <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <533622F3.2090406@fifthhorseman.net> <87eh18xtrl.fsf@alice.fifthhorseman.net> <53442983.1030703@pobox.com>
In-Reply-To: <53442983.1030703@pobox.com>
X-Enigmail-Version: 1.6+git0.20140323
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="q1XAIIIf3EqmoSmftJwbuEjPluKesn4td"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8jGfKto0cjnkolMcBxAN4jQRjLw
Cc: tls@ietf.org
Subject: Re: [TLS] Negotiated Discrete Log DHE revision [was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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 Apr 2014 00:53:51 -0000

On 04/08/2014 12:53 PM, Michael D'Errico wrote:
> There is already a list of DH groups managed by the IANA for IKE that was
> established by RFC 2409 and includes the MODP groups from RFC 3526 plus
> others.  Why not just use this existing registry and add your new e-based
> groups to it?

I tried to address this question in section 8.4 of the current draft:

https://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-01#section-8.4

-----------------
8.4.  Choice of groups

   Other lists of named discrete log Diffie-Hellman groups
   [STRONGSWAN-IKE] exist.  This draft chooses to not reuse them for
   several reasons:

      Using the same groups in multiple protocols increases the value
      for an attacker with the resources to crack any single group.

      The IKE groups include weak groups like MODP768 which are
      unacceptable for secure TLS traffic.

      Mixing group parameters across multiple implementations leaves
      open the possibility of some sort of cross-protocol attack.  This
      shouldn't be relevant for ephemeral scenarios, and even with non-
      ephemeral keying, services shouldn't share keys; however, using
      different groups avoids these failure modes entirely.

      Other lists of named DL DHE groups are not collected in a single
      IANA registry, or are mixed with non-DL DHE groups, which makes
      them inconvenient for re-use in a TLS DHE key exchange context.
-----------------

Do you find these arguments unconvincing, or do you have suggestions for
how the text should be changed?

	--dkg