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

Watson Ladd <watsonbladd@gmail.com> Sat, 28 June 2014 23:04 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 715F21A01C1 for <tls@ietfa.amsl.com>; Sat, 28 Jun 2014 16:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 harNjQttOPod for <tls@ietfa.amsl.com>; Sat, 28 Jun 2014 16:04:56 -0700 (PDT)
Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F7D1A01BE for <tls@ietf.org>; Sat, 28 Jun 2014 16:04:55 -0700 (PDT)
Received: by mail-yh0-f41.google.com with SMTP id z6so3993018yhz.14 for <tls@ietf.org>; Sat, 28 Jun 2014 16:04:55 -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 :content-type; bh=B3TXoFiF6xyKt+yMQshKvNubSaolluhlEWHalGq78t4=; b=mXrRhxRv+B3ka0hkxwFGrrhlbpH/HVTP+2oILComtgFAQF57l+5101sK5+wxnOEvHl dnD96OpZpCw5hJX6SP9a35gUA0xRsn5ITbLica172mhrcTorqeMd5YpMZBPX1WDbSwA5 EHuMQ36cRl9FWL9HCspr4Xg8oNdvOJTip7GRbAuj8AeaUpuCcQ7W2gppHy9KvaU3hF1C L0Qza4BggI7fEsCPPcUUt5b6OGTkUuV8pZI9vGgOW6qNDxfiwg6Bj/ctjaJfCU6+jFeR ZaYbffxYAdQeOj5W7377zPTR9prqntOsKVYcjLpXqBrZgQyg5263nle3Rla/vwnDiiQR xuFw==
MIME-Version: 1.0
X-Received: by 10.236.45.10 with SMTP id o10mr43357163yhb.49.1403996694925; Sat, 28 Jun 2014 16:04:54 -0700 (PDT)
Received: by 10.170.39.136 with HTTP; Sat, 28 Jun 2014 16:04:54 -0700 (PDT)
Received: by 10.170.39.136 with HTTP; Sat, 28 Jun 2014 16:04:54 -0700 (PDT)
In-Reply-To: <53AF47E3.9020906@nthpermutation.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>
Date: Sat, 28 Jun 2014 16:04:54 -0700
Message-ID: <CACsn0cmYbPeyUCMvRc=8MqVGMDSv1mKbxiQutqpPw_oR6cfD-A@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary=089e011615fc4455ea04fced7490
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GBrexfIm7kM-VRtLEa0NF0PynfE
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: Sat, 28 Jun 2014 23:04:58 -0000

On Jun 28, 2014 3:55 PM, "Michael StJohns" <msj@nthpermutation.com> wrote:
>
> On 6/28/2014 6:24 PM, Salz, Rich wrote:
>>>
>>> *sigh* If the IETF is really going to get into the business of
standardizing
>>> > crypto, we need to get the process for doing so right the first time
rather
>>> > than just plugging it in to TLS and hoping we don't have to redo it
over and
>>> > over again.
>>
>> Agree.  But again, it's "back into the business"  Because we did it
before with TLS1, IPsec, and ECC curves therein.
>
>
> Um... huh?  Can you provide specifics about which cryptographic
algorithms  we standardized?  This is news to me.

Camellia, RC4, HMAC. Of course we still screwed up TLS 1.0 by ignoring
lessons from IPSEC.

>
> And I'm not talking about "here's how you use ECDSA for TLS or ECDH for
for IPSEC" documents, but something comparable to SP800-56A or FIPS186-4 or
X9.63.

What's magical about ANSI? Furthermore,  we aren't developing an algorithm,
but documenting one that already exists, the way RFC 6090 claimed to.

There is nothing magical that makes using AES secure. You always have to
know what you are doing.

So I don't see picking curve25519 as inherently riskier then decisions we
make every day in this WG.
>
> Mike
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>