IETF Logo Mail Archive

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

Tony Arcieri <bascule@gmail.com> Fri, 05 June 2015 01:02 UTC

Return-Path: <bascule@gmail.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 D28B71ACDDB for <tls@ietfa.amsl.com>; Thu, 4 Jun 2015 18:02:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 7sQ0LjwyT_Vf for <tls@ietfa.amsl.com>; Thu, 4 Jun 2015 18:02:55 -0700 (PDT)
Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181121A8AD0 for <tls@ietf.org>; Thu, 4 Jun 2015 18:02:55 -0700 (PDT)
Received: by obbir4 with SMTP id ir4so2250172obb.1 for <tls@ietf.org>; Thu, 04 Jun 2015 18:02:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=LpLfcWFAowtPWziFLF3WUYV1zo27h8LDMrmTy+n32tA=; b=BAHTWQDh8f4VU39R/yf2fZUQpRZcrtC2QDDnFROEwyhW9p3uiB/5aS7vNvJW03mA+E yP8YXcHmQXBvflp9bN2UP8UEcPjrONbPIEAnrn4ngNm9aQ1CYE59Bm+8NP5F19oYvmUH U1OCypaFpI/BwfSAD7AuePCFnd+j4YtwRqGR5j+N2I1Bkai/eRr91+9XS3SlhtmS9rvM E52nnLzeWnO+kalHSxK/SmTMTLtOe4RhUbx0H+W8Z+1Nu+o2H7l6Vwe6agewB0YaGGVC q/JMkHmr6PXW+i2LUWw2jfmBdbNEVUs6Fe+8Oh09AdYYsXwZhR/RaQ3TOpRvE8E12TQW 8n2w==
X-Received: by 10.202.174.67 with SMTP id x64mr638402oie.50.1433466174550; Thu, 04 Jun 2015 18:02:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.110.241 with HTTP; Thu, 4 Jun 2015 18:02:33 -0700 (PDT)
In-Reply-To: <CAHOTMVJ1xu+mEaROWKuEtW1E8Ks3r3gKagEM9mJdBOKW3kSZJQ@mail.gmail.com>
References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com> <CAHOTMVJ1xu+mEaROWKuEtW1E8Ks3r3gKagEM9mJdBOKW3kSZJQ@mail.gmail.com>
From: Tony Arcieri <bascule@gmail.com>
Date: Thu, 04 Jun 2015 18:02:33 -0700
Message-ID: <CAHOTMVJwrg3Xzj1-dtMm6b1g9_rwn9KK=Wo-Mqxd7DnAygk8Hw@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a113cefa421c2a50517bada8f"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/u0GOmpoaykTWanetprXTY8gpke0>
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: Fri, 05 Jun 2015 01:02:57 -0000

As I expected, one of the major issues seems to be having a backup in the
event of a catastrophic failure of ECC:

On Mon, Jun 1, 2015 at 4:02 PM, Tony Arcieri <bascule@gmail.com> wrote:

> I expect the response is going to be "What if there's some catastrophic
> failure of ECC?"
>

On Wed, Jun 3, 2015 at 1:05 AM, Dave Garrett <davemgarrett@gmail.com> wrote:

> People want a backup to deal with mistrust of ECC curves


On Wed, Jun 3, 2015 at 3:05 AM, Nikos Mavrogiannopoulos <nmav@redhat.com>
 wrote:

> Removing the negotiation option means there there will
> be no backup at all in case of a flaw in the existing ECDHE
> ciphersuites.


When I did a quick straw poll of the CFRG about this, the seemingly
unanimous preference was if we do want to solve the general problem of an
"ECC backup", we should be focusing on post-quantum algorithms, not shoring
up FFDHE.

I get the "RHEL5 problem" but I really don't care (sorry RedHat). It's
basically the opposite of the kind of legacy support I was asking for,
where we solve problems by *shutting off* legacy ciphers. Instead, to solve
the "RHEL5 problem" we have to *further complicate TLS*.

It seems people are colluding support for ancient clients with the need for
a backup in the event of an ECC disaster.

I think the matter of what to do about a backup option in the event of an
ECCpocalypse is a question for the CFRG, not the TLS mailing list.

--
Tony Arcieri

v2.23.0 | Report a Bug | By Email