Re: [TLS] Obstacles to standardizing ECC in TLS

Eric Rescorla <> Mon, 09 June 2014 21:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DA1131A0341 for <>; Mon, 9 Jun 2014 14:55:50 -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 1-TgSy7Qg75E for <>; Mon, 9 Jun 2014 14:55:49 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 28EF91A0326 for <>; Mon, 9 Jun 2014 14:55:49 -0700 (PDT)
Received: by with SMTP id q59so1248824wes.41 for <>; Mon, 09 Jun 2014 14:55:47 -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=66Rfia3qi0BlB5ifASQkG+Gjadn25zQnZl0m8XNPg+U=; b=VFpR+woghv6pB5KwWOAQ9mbZcX/JFJpB5uaC83tZ5LhzuZfEKAgsSa1hPef/Wmcsq6 qFC2eNDKatoJqT/TwF8Z6wEtuEs+G52WNmZFzxI36wkMUkv6r+7fOAfFj1BP8lq653uy f5jfDyplsRENhY8EucSefn+oqteQG/uURlXYJyM7ktEg9wtLmCtl8JBGvwczojrZNsCT fAd7GFrs4ZVrYMVEum6uHCKRNzOZ9rBYVKy6WWrxkIZF4UJWHYYEWiETa6XyyO/xbQgk G1sUk5Wt73BRgJyeKYgI7lQNhOWdOtYwRo6Tmd3L0dDKCrIk7gCsR7/eZw7xmRth0EKH tEJw==
X-Gm-Message-State: ALoCoQmyQ6Wl9Jcchp4QimCbETRxpR6xKWxb2scFL3yHxMNBef1Z5Y6DlIr7MdJRdq5I31g5io2T
X-Received: by with SMTP id 11mr35861044wjs.48.1402350947492; Mon, 09 Jun 2014 14:55:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 9 Jun 2014 14:55:07 -0700 (PDT)
X-Originating-IP: [2620:101:80fc:232:c830:9a81:6768:eba4]
In-Reply-To: <>
References: <>
From: Eric Rescorla <>
Date: Mon, 9 Jun 2014 14:55:07 -0700
Message-ID: <>
To: Watson Ladd <>
Content-Type: multipart/alternative; boundary=047d7b3a834c137e3b04fb6e461a
Cc: "" <>
Subject: Re: [TLS] Obstacles to standardizing ECC in TLS
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: Mon, 09 Jun 2014 21:55:51 -0000

On Mon, Jun 9, 2014 at 2:40 PM, Watson Ladd <> wrote:

> Dear all,
> While I think that ECC ciphersuites and some well chosen curves need
> to be core, MTI features of TLS 1.3 for performance issues, I think
> there a few issues that need to be addressed.
> The first is that RFC 6090 is wrong: the formulas are incorrect, and
> so it should not be cited.
> The second is that the CFRG has not yet decided which curves to use.
> For legacy reasons implementations are likely to need to implement
> P256 and P384 for signature verification on certificates. However,
> there are significant advantages in speed and security for Edwards
> curves.
> I think it is high time to, 30 years after the invention of ECC, make
> it MTI in TLS. But I do not think it will be an immediately doable
> task.


Thanks for kicking off this conversation.

As you no doubt know, TLS already specifies a number of ECC-based
cipher suites (RFC 4492 and following) and there are interoperable
implementations of many of these cipher suites. The two relevant questions
for the TLS WG seem to me to be:

- Should at least some of them be on the standards track rather than their
current Informational status.
- If we do standardize some ECC cipher suites, should we make one or
more of them an (the?) MTI.

The primary relevance of RFC 6090 to this conversation is that it may
the IPR situation and thus smooth the way to putting these ciphersuites on
Standards Track.

I have made to track
this topic.