IETF Logo Mail Archive

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

Eric Rescorla <ekr@rtfm.com> Sat, 28 June 2014 23:51 UTC

Return-Path: <ekr@rtfm.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 E27381A01E4 for <tls@ietfa.amsl.com>; Sat, 28 Jun 2014 16:51:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 NLTyRdj7ow8t for <tls@ietfa.amsl.com>; Sat, 28 Jun 2014 16:51:43 -0700 (PDT)
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8EA91A01BE for <tls@ietf.org>; Sat, 28 Jun 2014 16:51:42 -0700 (PDT)
Received: by mail-wi0-f182.google.com with SMTP id bs8so4315288wib.9 for <tls@ietf.org>; Sat, 28 Jun 2014 16:51:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7Jp2XvUsF4VViVc6shyK1CM+PwLkNaYOfl45ttyp98w=; b=jMvgD96xB15tJbG9ma837VSp8yfyswA3RegDfAXXj7O01khwJPMLCSpfuuqh5JMMhH +TUz8jKQEhBr+GY5nFIi1EaS02oyXt3lVm85pARXsQhJf9pNn4U3UZ9YIp4Gned7FFxy UMK3bAOW6N3vP2kVppOt6ixuRbYsGF932y0dndHu/FrjbrdSx27wXBvwFuWLbngRQwPo RK5MPMXgw4MVayuKPVY/Owx1gr8yL+t84E+BCjCzxV5ihZWNxu+GnhPcC1W2Iz8NFNU1 b004eZMwESPTuB9fmAKbhWo1nVRFfHNKYmKoOcgBjAhTMF5l9TcjxZFyhAhD45OzIzrM Aqew==
X-Gm-Message-State: ALoCoQkJGQtk27/5XbAgVl+Y1CBMyScDgBPVB8Yykj9R7apYROHnbhPc7+zbbB+rmzIpABOjYSa0
X-Received: by 10.194.48.103 with SMTP id k7mr34456172wjn.68.1403999501358; Sat, 28 Jun 2014 16:51:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.218.198 with HTTP; Sat, 28 Jun 2014 16:51:01 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <53AF517F.7050504@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> <CACsn0cmYbPeyUCMvRc=8MqVGMDSv1mKbxiQutqpPw_oR6cfD-A@mail.gmail.com> <53AF517F.7050504@nthpermutation.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 28 Jun 2014 16:51:01 -0700
Message-ID: <CABcZeBMs+03GefqNaBbhF8FRdw_Pmpe6NkDqesssb-FruRaEdw@mail.gmail.com>
To: Michael StJohns <msj@nthpermutation.com>
Content-Type: multipart/alternative; boundary="047d7b86c8e48b2c9504fcee1b9b"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9FoLHGaA_z06NvWXozYvOMVRij4
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: Sat, 28 Jun 2014 23:51:48 -0000

On Sat, Jun 28, 2014 at 4:36 PM, Michael StJohns <msj@nthpermutation.com>
wrote:

>  On 6/28/2014 7:04 PM, Watson Ladd wrote:
>
>
> 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.
>
>
> I can't find an RC4 RFC, but Camellia and HMAC are both Informational
> rather than Standards track.
>

I'm not sure why this is a relevant distinction. These documents are
published by IETF and we make normative references to them in
Standards Track documents. See, for instance:

http://datatracker.ietf.org/doc/rfc2104/referencedby/



> The IETF does not own change control on either of these.
>

How does this matter? Unlike protocols, cryptographic algorithms aren't
really versioned. If we wanted to do a new version of HMAC, we would
presumably call it HMAC-2 or something. What's needed is a stable
reference.

-Ekr

v2.23.0 | Report a Bug | By Email