Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,

Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 01 July 2014 14:36 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 5412E1B2805 for <tls@ietfa.amsl.com>; Tue, 1 Jul 2014 07:36:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] 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 frU70KqCcWd4 for <tls@ietfa.amsl.com>; Tue, 1 Jul 2014 07:36:13 -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 000181B2804 for <tls@ietf.org>; Tue, 1 Jul 2014 07:36:10 -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=1404225373; x=1435761373; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=bYCZJCrVEaUXTAhxUB+04v4R5pS/0MGQARyw7r6smqc=; b=tT/2ozGewPuU/usStuGqkcxh1JY4UtXuAcLgrdShQVWG/Le7FEaus1to bvEFwpNlr1EBusznOGv8MF6uMfLEPKv9vKZu4nliq/Bo704eut6RY8hr7 R8QcNWEu1nCc23T24A9iLq6bpAP3v3FdX0oe4uH5BRPSufrsVaJwZQJg/ E=;
X-IronPort-AV: E=Sophos;i="5.01,581,1399982400"; d="scan'208";a="261455026"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 02 Jul 2014 02:36:08 +1200
Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.9]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Wed, 2 Jul 2014 02:36:08 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,
Thread-Index: Ac+VOctlducJCFxkRkONHcPFxq3oJQ==
Date: Tue, 1 Jul 2014 14:36:07 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C738DED183A@uxcn10-tdc06.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/EHQOBNKNOyOk_PwHy73JRSq_4CE
Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,
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, 01 Jul 2014 14:36:17 -0000

Fedor Brunner <fedor.brunner@azet.sk> writes:

>Also Adam Langley thinks that NIST continually pick algorithms that aren't
>suited to software implementations.
>https://www.imperialviolet.org/2012/10/21/nist.html

Another problem with the NIST standards is that, once you go beyond basics
like AES, SHA-2, and so on, you have a neverending stream of oddball modes and
mechanisms that no standard protocol ever uses, or arguably needs.  However
since it's specified by NIST, standards groups, who are often heavily stacked
with US contributors, feel the need to force them into all manner of standards
because they feel they need USG approval for them.  

This applies particularly to things like TLS, less so for protocols like SSH
(if I had a penny for every time I've heard "we can't do <straightforward
common-sense approach> because there's no NIST-approved way to do it" or "we
need to do <some boneheaded silly-walk> because that's what the NIST standard
says"...).  In other words while the SSH effort is driven by purely technical
considerations, things like TLS are driven by a combination of technical
considerations and "what NIST has standardised so we can get it FIPS certified
for our USG customers".

This dual technical+political approach is not a good way to design a standard.

Peter.