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

Nigel Smart <nigel@cs.bris.ac.uk> Mon, 30 June 2014 19:16 UTC

Return-Path: <csnps@bristol.ac.uk>
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 C03291A0416 for <tls@ietfa.amsl.com>; Mon, 30 Jun 2014 12:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 eV6PnKJsjKoH for <tls@ietfa.amsl.com>; Mon, 30 Jun 2014 12:16:18 -0700 (PDT)
Received: from eu1sys200aog133.obsmtp.com (eu1sys200aog133.obsmtp.com [207.126.144.209]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E11341A03C6 for <TLS@ietf.org>; Mon, 30 Jun 2014 12:16:17 -0700 (PDT)
Received: from mail-wg0-f51.google.com ([74.125.82.51]) (using TLSv1) by eu1sys200aob133.postini.com ([207.126.147.11]) with SMTP ID DSNKU7G3fWxboGEpuFJt1lzMkM8KcZU7kgwf@postini.com; Mon, 30 Jun 2014 19:16:18 UTC
Received: by mail-wg0-f51.google.com with SMTP id x12so8413788wgg.34 for <TLS@ietf.org>; Mon, 30 Jun 2014 12:16:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:message-id:date:from:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=SjHB7p0aj2mgpRvsziDwDYVPfDG1PZKUts+w8S0wnNY=; b=C8xVl84kyqhhx7KkNwYLEykvDsORrZ0xHBK2BzgS6citTflHP+0sRmoztQgC/e/yYj J3TQYd7eM2pYuBteOMO13vwCgqdh4646SFrE9YwzcYbNo50MiIIAEk4ubU63kXM2OV0b xyERkZ/7VmYgZieCGG1qPs4xzh2xjWUcjVznQEMgP4slmNHtPL8kvXY1VXR+3ewzhKcw EVA1y8Fll4nrAcZIPWi3pee/DqjREJQsVziGkEN7Xc7c273YhJbc544+sxiBc1/Dm8UQ tj5aShM/gcn8SyxGsgdCP3PF6HSflv39VavAKQoBlGQ6KK49ktsdYxK4h/abSghNRHOh uDCg==
X-Gm-Message-State: ALoCoQmK4VKRSVLfeq6KDWjYyv4oc1+fLaSz65GGy9DXChbsdMK89VMVdlF3VVyUUoIY2Vz8BDRzn7GWLBgtWmKnr1e1tYIVRw+uzkGp6PLQhM5XUJxELE7w6iZ1aPpr2okYwMcej28I
X-Received: by 10.194.22.201 with SMTP id g9mr5654731wjf.98.1404155773615; Mon, 30 Jun 2014 12:16:13 -0700 (PDT)
X-Received: by 10.194.22.201 with SMTP id g9mr5654722wjf.98.1404155773502; Mon, 30 Jun 2014 12:16:13 -0700 (PDT)
Received: from [192.168.1.78] (host86-159-137-103.range86-159.btcentralplus.com. [86.159.137.103]) by mx.google.com with ESMTPSA id fw4sm34458524wib.19.2014.06.30.12.16.11 for <TLS@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 12:16:12 -0700 (PDT)
Sender: Nigel Smart <csnps@bristol.ac.uk>
Message-ID: <53B1B77C.2060201@cs.bris.ac.uk>
Date: Mon, 30 Jun 2014 20:16:12 +0100
From: Nigel Smart <nigel@cs.bris.ac.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: TLS@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xlggnqsnXRDXTfxvrPSQoXiHlgo
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: Mon, 30 Jun 2014 19:16:20 -0000

> Nobody's asking the IETF, little more than a collection of mailing lists, to take liability should 25519 be cracked or have a back door.

What's the difference between defining a cryptographic protocol (i.e. 
TLS 1.3)
which could have lots of problems/be cracked/have a back door; and defining
a cryptographic algorithm which could have lots of problems/be cracked/have
a back door? Experience shows us that defining cryptographic protocols
(key agreement/secure channels) is more prone to problems than defining
cryptographic primtives (AES, ECC).

If IETF is just a collection of mailing lists, and no one takes 
responsibility
for the security implications of the security bits in it, then what is 
the point
of TLS 1.3?
    - But then again the collection of mailing lists is what resulted in 
TLS 1.2
      So in some sense TLS 1.3 is to correct the output of a collection 
of mailing
      lists which produced TLS 1.2               :-)

My personal opinion is that the IETF should use
    i) Externally validated cryptographic primitives (i.e. AES, SHA-3, 
specific ECC
       choices etc).
   ii) Externally validated cryptographic protocols (i.e. throw out most of
       existing TLS methodology). Finding external validation of 
protocols is
       however currently a problem. Since TLS 1.3 is meant to offer a 
key agreement
       protocol and a secure channel protocol; and there are very few 
standards
       for such things.

Now 25519 is both. It is a cryptographic primitives (a specific elliptic 
curve)
AND an associated protocol (the specific form of key agreement protocol
which uses the said curve).  Given neither have any form of external 
validation
I do not think IETF should use them.

Nigel