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

Nigel Smart <> Mon, 30 June 2014 19:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C03291A0416 for <>; Mon, 30 Jun 2014 12:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eV6PnKJsjKoH for <>; Mon, 30 Jun 2014 12:16:18 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E11341A03C6 for <>; Mon, 30 Jun 2014 12:16:17 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Mon, 30 Jun 2014 19:16:18 UTC
Received: by with SMTP id x12so8413788wgg.34 for <>; Mon, 30 Jun 2014 12:16:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id g9mr5654731wjf.98.1404155773615; Mon, 30 Jun 2014 12:16:13 -0700 (PDT)
X-Received: by with SMTP id g9mr5654722wjf.98.1404155773502; Mon, 30 Jun 2014 12:16:13 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id fw4sm34458524wib.19.2014. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 12:16:12 -0700 (PDT)
Sender: Nigel Smart <>
Message-ID: <>
Date: Mon, 30 Jun 2014 20:16:12 +0100
From: Nigel Smart <>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 
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 
       for such things.

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