Re: [Cfrg] [TLS] Unwarrented change to point formats

Watson Ladd <> Sun, 27 July 2014 20:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2AA231A032F for <>; Sun, 27 Jul 2014 13:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yV2ahZSWNm8m for <>; Sun, 27 Jul 2014 13:39:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 88F3E1A032C for <>; Sun, 27 Jul 2014 13:39:56 -0700 (PDT)
Received: by with SMTP id t59so4313448yho.39 for <>; Sun, 27 Jul 2014 13:39:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uj/qtjEfpmVV17v2ZkjSKi0/IJjb0v9WA7Sq1KvOy0k=; b=uVTAKEwGhJLXbCJlC0P0cZZ5fv0A9XLRlbWcuTMw850JTM6VkL70xAKkC4T/eBKS4y 4METsbIQUi9KFUX3SkRaKBLW8QQFOtMf/75yNcvFYDNs2n4FRn/i6xUUA6UvL6dy2fn/ Gmq13YA7jW4yqtnRi8PhtNnB+epFO999X2EZeGRtUgBni3KKYy5tz41CTv5pTc124hJh 9DdsQoO8P67zb0208oLXHvu8La3FsdP8plZRfJpk01Z3ycSG5rxt1shTGGwxnsdyxiZB dmxlbRMH4M96N00OWhFGBSzmUKkxAX4dhf9xk0lAW950GRpm45M0qEeLG49zlJMTrkSg GEKA==
MIME-Version: 1.0
X-Received: by with SMTP id u56mr45316861yhe.48.1406493595862; Sun, 27 Jul 2014 13:39:55 -0700 (PDT)
Received: by with HTTP; Sun, 27 Jul 2014 13:39:55 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Sun, 27 Jul 2014 13:39:55 -0700
Message-ID: <>
From: Watson Ladd <>
To: Eric Rescorla <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>, "" <>
Subject: Re: [Cfrg] [TLS] Unwarrented change to point formats
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 27 Jul 2014 20:39:58 -0000

On Sun, Jul 27, 2014 at 1:26 PM, Eric Rescorla <> wrote:
> 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.

This kind of analysis is much easier than the kind the TLS WG has to engage
in to ensure no more surprises. In particular since a lot of the
issues have to do
with performance and uptake, it's not clear the CFRG knows more about them then
the TLS WG.

> 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
> signatures
> 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.

You had a draft in hand, got a reply that "yeah, looks good", and then
went back to ask for
a completely different design process, for reasons never discussed.
It's the second round
that's confusing me.

What was wrong with the curve25519 draft?

Watson Ladd

> -Ekr

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