Re: [TLS] Unwarrented change to point formats

Eric Rescorla <> Sun, 27 July 2014 20:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CC2D51A0242 for <>; Sun, 27 Jul 2014 13:27:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qYjY5D-n608O for <>; Sun, 27 Jul 2014 13:27:14 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF8AA1A01D9 for <>; Sun, 27 Jul 2014 13:27:13 -0700 (PDT)
Received: by with SMTP id n3so3391481wiv.5 for <>; Sun, 27 Jul 2014 13:27:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XlmZlu4kgD9eyimWgxiaXBVB4SY1ryNqv/kVESNtMis=; b=iaaWMu2aavf+6tg9kicGIJ5Ieiv/1dAUvVFm+6viMYSwZlfthSfIbCECU/SylQCsC/ P285VeerZs+jRF+x8BV4DdczlO9txDWY7BS5KalR0DCQJeTIDvueXQBIGOmk131lle8C GCzD0FOCDetn90Al7LlUs3/TPzW6ti2bJExV6gWeyrIJl1kSzAl1WJWkcW8NOFHWy5LX y1ByfpEzIKBozFIijZkGMRWagQXdhXt/wAp6dQvwaJ/MnszNUitI4BHN+Pp5CznCwag4 uL4jmWlaFa+1o+CDanKzaXq07hKak1hP69ccYjjxXjBkl4ZLA9UT2jI79910lmFJSq/e 3d1A==
X-Gm-Message-State: ALoCoQnLE/hPWKSLq0smMgZsROE6Gw3ymEkC7Ldsc2nbIuR3qyPahyOc7lW916ouPXzztpN8FIEH
X-Received: by with SMTP id s1mr23773693wiz.36.1406492832417; Sun, 27 Jul 2014 13:27:12 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 27 Jul 2014 13:26:32 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <>
From: Eric Rescorla <>
Date: Sun, 27 Jul 2014 13:26:32 -0700
Message-ID: <>
To: "Paterson, Kenny" <>
Content-Type: multipart/alternative; boundary=f46d04428610a7e8ae04ff32a141
Cc: "" <>, "" <>
Subject: Re: [TLS] Unwarrented change to point formats
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: Sun, 27 Jul 2014 20:27:16 -0000

On Sun, Jul 27, 2014 at 11:25 AM, Paterson, Kenny <
> wrote:

> Watson,
> There was certainly support for Curve25519 at the CFRG interim phone
> conference, from my reading of the transcript.
> I don't think the reasons for the TLS WG to ask for our input are
> nebulous, as you put it. I'd say they were taking a responsible approach,
> charging us as experts to explore the alternatives carefully and make
> recommendations. This choice will affect the future security of TLS for
> years - or decades - to come. So we have to get it right.

This reflects my understanding as well.

> That request to us does not mean anyone is ignoring existing drafts, as
> you write. I am also not aware of this IETF-wide requirement that you
> mention. I believe it's a "nice to have", but not a hard requirement.

Speaking only for myself, I don't think there's anything particularly
mysterious here. The TLS WG is not chartered to do this kind of analysis
so we've turned to the CFRG. It would clearly be most efficient if the IETF
had a common set of cryptographic primitives where possible. It's true
that TLS was the first WG to try to write down a specific request, but it
seems likely that our needs are mostly common with other protocols.

To take a specific set of cases. TLS has three major uses for public key
crypto of this type:

- Key establishment
- Digital signatures over handshake messages (ServerKeyExchange,
  CertificateVerify, etc.)
- Digital signatures over certificates.

It seems likely that key establishment shares common requirements for
multiple protocols. Similarly, it would be quite convenient if the
used in TLS were the same as those used for the certificates used for TLS,
even though the latter are not defined in TLS. So, when I say an IETF-wide
set of recommendations that's the kind of thing I mean.

I wasn't aware that any of this was particularly controversial.