IETF Logo Mail Archive

Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt

Nikos Mavrogiannopoulos <nmav@redhat.com> Wed, 03 June 2015 10:05 UTC

Return-Path: <nmav@redhat.com>
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 9CE511A00F4 for <tls@ietfa.amsl.com>; Wed, 3 Jun 2015 03:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 9Q2aMmVLJp6B for <tls@ietfa.amsl.com>; Wed, 3 Jun 2015 03:05:56 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6635C1A00E1 for <tls@ietf.org>; Wed, 3 Jun 2015 03:05:56 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id DF70ABF9DF; Wed, 3 Jun 2015 10:05:55 +0000 (UTC)
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t53A5rUq008284 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 3 Jun 2015 06:05:54 -0400
Message-ID: <1433325951.10465.9.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Tony Arcieri <bascule@gmail.com>
Date: Wed, 03 Jun 2015 12:05:51 +0200
In-Reply-To: <CAHOTMVLTt8d8AORa3ymOby9FhJqHb7Qq28tJT6+QdoM+4WBhdA@mail.gmail.com>
References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <CAHOTMVJ1xu+mEaROWKuEtW1E8Ks3r3gKagEM9mJdBOKW3kSZJQ@mail.gmail.com> <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> <CAHOTMVJgqqRBYWR+8LtwxfdRVWxEXLZAgzr5Q-1DH7ejONAGnw@mail.gmail.com> <m2lhg1b8us.fsf@localhost.localdomain> <CAHOTMVLrgUNi449DQwggt556ioEeXCQTUN+M3phBftPk88xtOw@mail.gmail.com> <BLU177-W17E87DB68F54CE64BDC44C3B40@phx.gbl> <CAHOTMVLpmS94cBZOxu6e3-e2MMO+Z0SAvPb7dWW47jQqXpT9+A@mail.gmail.com> <BLU177-W1EA1B34A70F648FD8C139C3B40@phx.gbl> <CAHOTMV+FxxG7tpq55UyKs+q06uk5H-dCqkTswBDJsM=5Bv6pqA@mail.gmail.com> <9A043F3CF02CD34C8E74AC1594475C73AB034F5F@uxcn10-tdc05.UoA.auckland.ac.nz> <CAHOTMVJM7tw8gDzaAOxoi39aC3v_PycFay3Jg6e09Wx5k9H4cw@mail.gmail.com> <9A043F3CF02CD34C8E74AC1594475C73AB034FEB@uxcn10-tdc05.UoA.auckland.ac.nz> <CAHOTMVLTt8d8AORa3ymOby9FhJqHb7Qq28tJT6+QdoM+4WBhdA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/1n8MH1uTgKE-t_sCytiFGGqrdL0>
Cc: TLS WG <tls@ietf.org>, Geoffrey Keating <geoffk@geoffk.org>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt
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, 03 Jun 2015 10:05:57 -0000

On Wed, 2015-06-03 at 01:48 -0700, Tony Arcieri wrote:
> We can either double down on the gunk, or shut it off.
> *In practice* I have been telling people to shut it off and so far 
> it's been a successful solution to the problem.
> Why should we keep this legacy gunk around? Who is it helping?

I agree that DHE is old and slow comparing to ECDHE and typically you
wouldn't want it. However, it is one question to disable the
ciphersuites you don't want, and another to remove DHE as a negotiation
option for TLS. Removing the negotiation option means there there will
be no backup at all in case of a flaw in the existing ECDHE
ciphersuites.

If you plan to serve buggy clients with broken DHE support, then the
simplest approach is not to offer DHE to them. If you are in control of
these broken clients, then disable DHE support in them. The draft is
only slightly related to the issues you present on this thread.

regards,
Nikos

v2.23.0 | Report a Bug | By Email