Re: [Cfrg] [TLS] 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: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63321A0AB5 for <cfrg@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=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 pp0zpHXoUXBf for <cfrg@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 C26D61A0AB4 for <cfrg@irtf.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/cfrg/c4LhCfZSLMgkKyW4D1F-Ik0lS68
Subject: Re: [Cfrg] [TLS] Formal request from TLS WG to CFRG for new elliptic curves
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.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.