Re: [TLS] Should we require compressed points

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 28 October 2014 14:52 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 C08951A8A0B for <tls@ietfa.amsl.com>; Tue, 28 Oct 2014 07:52:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6] autolearn=no
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 mSuhdS1FJwix for <tls@ietfa.amsl.com>; Tue, 28 Oct 2014 07:52:25 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C9F1A89B5 for <tls@ietf.org>; Tue, 28 Oct 2014 07:52:25 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4BEAD2AB2BB; Tue, 28 Oct 2014 14:52:24 +0000 (UTC)
Date: Tue, 28 Oct 2014 14:52:24 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20141028145223.GQ19158@mournblade.imrryr.org>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D6102@uxcn10-5.UoA.auckland.ac.nz> <CABcZeBOWR4BVy0e3TY3FVB8wqOwrUgD6OfHLTJS_iXUZv30CsA@mail.gmail.com> <544F635D.2000309@polarssl.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <544F635D.2000309@polarssl.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/d_i2-5a65tPyYn7DWPO8wULvJdY
Subject: Re: [TLS] Should we require compressed points
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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: Tue, 28 Oct 2014 14:52:26 -0000

On Tue, Oct 28, 2014 at 10:35:25AM +0100, Manuel P?gouri?-Gonnard wrote:

> On 27/10/2014 23:10, Eric Rescorla wrote:
> > As I said above, I'm principally trying to get rid of negotiation so we have
> > one point format for each curve. I could certainly live with requiring 
> > uncompressed only for the X9.62 curves and then defining a new, cleaner
> > format for the new CFRG curves.
>
> If the goal is to get rid of negotiation, would it be reasonable to say that
> implementations MUST support both formats?

I think that Bodo's suggestion of separate IANA assignments for
compressed and uncompressed variants of curves makes the most sense.

With that, clients that need to interoperate with TLS <= 1.2 can
send the point format extension indicating uncompressed format for
legacy curves, and include the code points for the legacy
format-ambiguous curves, and send new code points for (some of the
same underlying) curves that have an implied format.

Brand new curves would then ideally be registered with a single
preferred point format that is most suitable for the curve.

-- 
	Viktor.