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

Watson Ladd <watsonbladd@gmail.com> Mon, 30 June 2014 04:36 UTC

Return-Path: <watsonbladd@gmail.com>
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 55D411A0162 for <tls@ietfa.amsl.com>; Sun, 29 Jun 2014 21:36:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 pWA79TjMrU5u for <tls@ietfa.amsl.com>; Sun, 29 Jun 2014 21:36:06 -0700 (PDT)
Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85EAB1A014B for <tls@ietf.org>; Sun, 29 Jun 2014 21:36:06 -0700 (PDT)
Received: by mail-yk0-f170.google.com with SMTP id q9so4368758ykb.29 for <tls@ietf.org>; Sun, 29 Jun 2014 21:36:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tKRxo/nZSzZate3o7K2Y6DAEacjE8FS/EJcYXQHXyQ4=; b=mJ5Outlbp34TeMZliyRfvMCkRsPiFK9bErSDpteSZxeGo0hPQJ4Gcqf/ZyZsImI6Fh mqDxaDwszH02aQ6t/E4NzFnwj47GudiujL3WRcK0PBcDbv5Pnkm3ChT4oFuZh+8MJDG1 vjwRwQxAcNcHTD5En0oJ+FMwC5Jvfgq8qRSbiSJq65QXepFt5e5bEmrhVX9LABDFPc1T ZSv4frxVN5GL4zIWAdNVeKFSeI3zjnCDLiuc0QinuGHU0nAy5uAAp7xzVhj/9FL0hqCh w2NqgljVFAu2iEd6eqOK6l4xRUyFX/EMIgtSqjhfjbwknhuGIN3GJPrkrv5TQTMINI9g LYeA==
MIME-Version: 1.0
X-Received: by 10.236.172.161 with SMTP id t21mr55795875yhl.65.1404102965705; Sun, 29 Jun 2014 21:36:05 -0700 (PDT)
Received: by 10.170.39.136 with HTTP; Sun, 29 Jun 2014 21:36:05 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA95@USMBX1.msg.corp.akamai.com>
References: <53AC97B8.2080909@nthpermutation.com> <CABcZeBN5uY4bteXW=OFC1z3ANoSC8AqxG6E6artdOKPF=VxdJg@mail.gmail.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA48@USMBX1.msg.corp.akamai.com> <53AF47E3.9020906@nthpermutation.com> <CACsn0cmYbPeyUCMvRc=8MqVGMDSv1mKbxiQutqpPw_oR6cfD-A@mail.gmail.com> <53AF517F.7050504@nthpermutation.com> <CABcZeBMs+03GefqNaBbhF8FRdw_Pmpe6NkDqesssb-FruRaEdw@mail.gmail.com> <53B07640.2050000@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA95@USMBX1.msg.corp.akamai.com>
Date: Sun, 29 Jun 2014 21:36:05 -0700
Message-ID: <CACsn0cm1TvZsdreOK7WejWqOqU4SNAcvKRyy5sSZMJjyYzq1=Q@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GF-cAeWsErEmQ-yTsSE76YBxNvA
Cc: "tls@ietf.org" <tls@ietf.org>
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 04:36:08 -0000

On Sun, Jun 29, 2014 at 8:12 PM, Salz, Rich <rsalz@akamai.com> wrote:
> Ø  Implication: The IETF will have to make some pronouncement or assurance
> as to the viability of Curve25519 to the wider world.  The IETF will have to
> maintain the Curve25519 standard.
>
> Mike, I know you’ve been involved in this stuff since before this stuff
> existed J, but I don’t understand this. Why do we have to make any assurance
> about anything other than ‘here is how to interoperate using 25519 in TLS’?

No, we are defining a standard, and we are making assurances. Let's
not kid ourselves: SPF might say experimental, but if you try to send
mail without it, you'll find out just how much of a standard it is. As
for making assurances, if someday a massive break is discovered in TLS
1.3 because we neglected cryptographic knowledge, we will rightfully
be blamed for it.

If 25519 was ROT13, a proposal to include it would rightfully be
laughed out of this WG. We've established the principle, now we're
just haggling over its limits.

Sincerely,
Watson Ladd

>
>
>
> We’re not defining a standard, we’re not assuring the world about anything.
> We’ll have an RFC that says “here’s  how to do the math for 25519 and other
> things needed to interoperate” and we’ll have other RFC’s that say “here’s
> how to use that curve in this protocol.”
>
>
>
> Why does it need to be more than that?  I know that I am not alone in this
> confusion.
>
>
>
>                 /r$
>
>
>
> --
>
> Principal Security Engineer
>
> Akamai Technologies, Cambridge, MA
>
> IM: rsalz@jabber.me; Twitter: RichSalz
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin