[TLS] Obstacles to standardizing ECC in TLS

Watson Ladd <watsonbladd@gmail.com> Mon, 09 June 2014 21:40 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 88DF71A0326 for <tls@ietfa.amsl.com>; Mon, 9 Jun 2014 14:40:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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=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 L-Sara8B8MfM for <tls@ietfa.amsl.com>; Mon, 9 Jun 2014 14:40:04 -0700 (PDT)
Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276801A01CF for <tls@ietf.org>; Mon, 9 Jun 2014 14:40:04 -0700 (PDT)
Received: by mail-yh0-f48.google.com with SMTP id b6so1668981yha.7 for <tls@ietf.org>; Mon, 09 Jun 2014 14:40:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Ur2AycDQOHjMvxPGSV+C0CrkN0CUU9OTy5P6mOghonQ=; b=tnMiwOd/rLOxdiiCdC5aEAbMcoO+nDK7WPfSJ4Tu5OPnerHWS80K5d2KyboGiMTn8I PnHDxbouyFKcwb26eYHo5u6odnlPyAlhD4PbvHT6PD5T9j+7/Pd+zCil+JKmGcR2ppwt 1N3EPHfs4HRIkrONCa9OnhZ6lV+E6C9JJDR0WcxZqbsr2EFhXSur96LQiyxQqK3XwUJP vx7b/3h7dj+BsDyBjSGKoeHnMss1dxOYeLTZwi67iJz3fFy37BEpU4T/HTGDVSPC7JLX b5rPmc0uS5PP7Z9RMNS9UISQ56uvYEDKj/x+LYXwf01PTIiJypuzXaY1EOhxzC642lu+ yFFw==
MIME-Version: 1.0
X-Received: by 10.236.26.72 with SMTP id b48mr17498586yha.59.1402350003551; Mon, 09 Jun 2014 14:40:03 -0700 (PDT)
Received: by 10.170.39.136 with HTTP; Mon, 9 Jun 2014 14:40:03 -0700 (PDT)
Date: Mon, 9 Jun 2014 18:40:03 -0300
Message-ID: <CACsn0ckhfGrcvAfuF+z5vjQ-tert0NPNSg6oAQyJk87mGpvv8A@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8rXaT4dI_pGSUJ7gO6xiDzqhq54
Subject: [TLS] Obstacles to standardizing ECC in TLS
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: Mon, 09 Jun 2014 21:40:05 -0000

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.

Sincerely,
Watson Ladd