Re: [TLS] [Cfrg] Formal request from TLS WG to CFRG for new elliptic curves
Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 22 July 2014 10:40 UTC
Return-Path: <pgut001@cs.auckland.ac.nz>
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 ABB081A0AB7 for <tls@ietfa.amsl.com>; Tue, 22 Jul 2014 03:40:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=unavailable
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 rtN6ZQiNe0A0 for <tls@ietfa.amsl.com>; Tue, 22 Jul 2014 03:40:18 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25B61A05D1 for <tls@ietf.org>; Tue, 22 Jul 2014 03:40:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1406025618; x=1437561618; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=IcsCmaWWOruvsmYVGsky+rFys8pSSSIIOXESBu5FHik=; b=WgsNDrEFEH3IqwzyXbua3chxs5x10/Fy+vyj58c3HUjt2akyve6SARAa g6yPYZAqg0DnYuc6AJS3Ubdc2kjWlhTynWQS/aZn0fbBZfsINEpbvp27d 1ZEp6MfnnbKfe2zTGxTZmO6stLm/XRkJY4als7WFBh7VDDWDA3SbiXE4I g=;
X-IronPort-AV: E=Sophos;i="5.01,709,1399982400"; d="scan'208";a="265151160"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 22 Jul 2014 22:40:15 +1200
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.247]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 22:40:15 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "tls@ietf.org" <tls@ietf.org>, "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [TLS] [Cfrg] Formal request from TLS WG to CFRG for new elliptic curves
Thread-Index: Ac+lmVKBp1FFM2f1RJS1LzlOl6ghTQ==
Date: Tue, 22 Jul 2014 10:40:15 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C738EFAE9B3@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CmOf53BLbOQMwiySQaSbz5V2Jgc
Subject: Re: [TLS] [Cfrg] Formal request from TLS WG to CFRG for new elliptic curves
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: Tue, 22 Jul 2014 10:40:23 -0000
"Salz, Rich" <rsalz@akamai.com> writes: >> TLS 1.2 offered no compelling advantages. > >Yes. TLS 1.3 will offer some good reasons to adopt, from the simplicity, >security, privacy, and efficiency areas. The comparison to TLS 1.2 doesn't >hold. TLS 1.3 will also offer a really strong reason to defer adoption for as long as possible: Unlike the previous tweaks of SSL, which did lead to the frankensteinian implementation we have to deal with now but at least were close to the original, TLS 1.3 is pretty much an entirely new protocol. I have no idea what it'll end up looking like once the design committee has finished adding every feature everyone's ever wanted in a protocol to it, but it's most likely going to be TLS 2.0 even if it's called TLS 1.3. That means a completely new implementation from scratch rather than trying to add yet another layer to what started long ago as an SSL implementation, and deploying a new protocol up against SSL/TLS, even if it's sold as TLS-something, will be a huge uphill battle. Look at how long TLS 1.2 adoption took, outside of web browsers it's still very much the exception rather than the rule (and even for web browsers there are some amazing calisthenics they perform in order to make things work for non-TLS 1.2 servers and devices). Peter.
- Re: [TLS] [Cfrg] Formal request from TLS WG to CF… Watson Ladd
- Re: [TLS] [Cfrg] Formal request from TLS WG to CF… Salz, Rich
- Re: [TLS] [Cfrg] Formal request from TLS WG to CF… Benjamin Black
- Re: [TLS] [Cfrg] Formal request from TLS WG to CF… Peter Gutmann