Re: [TLS] Should we require compressed points

Manuel Pégourié-Gonnard <mpg@polarssl.org> Tue, 28 October 2014 16:26 UTC

Return-Path: <mpg@polarssl.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 7C2F81A8F4C for <tls@ietfa.amsl.com>; Tue, 28 Oct 2014 09:26:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.997
X-Spam-Level:
X-Spam-Status: No, score=0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 DauqEhcaKlg6 for <tls@ietfa.amsl.com>; Tue, 28 Oct 2014 09:26:08 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 744A01A9025 for <tls@ietf.org>; Tue, 28 Oct 2014 09:24:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=KOSw+fE3aJvrWuR11y3lRoXm0xoHJdsr6PgoabZqPgM=; b=Qru1FI9US93iDtTNUfXcwel1fvzSyTDkCf6E2Y7mnfOGr/vTQ2JbbCrhH4X8rOH4REqyDyvTx1pLFYDYehJ6KcgrrcrViUyvixTPWIcYmkNKFvz9FcvPXgUwQPv9SPLlj9lcjZKf90wqiTlzFSPzEQmKqgEL6K9fmOpY2PflqkM=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1Xj9ZE-0008V9-WD for tls@ietf.org; Tue, 28 Oct 2014 17:24:21 +0100
Message-ID: <544FC339.8010605@polarssl.org>
Date: Tue, 28 Oct 2014 17:24:25 +0100
From: Manuel Pégourié-Gonnard <mpg@polarssl.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C739B9D6102@uxcn10-5.UoA.auckland.ac.nz> <CABcZeBOWR4BVy0e3TY3FVB8wqOwrUgD6OfHLTJS_iXUZv30CsA@mail.gmail.com> <544F635D.2000309@polarssl.org> <20141028145223.GQ19158@mournblade.imrryr.org>
In-Reply-To: <20141028145223.GQ19158@mournblade.imrryr.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dUdoZm9oHR2ax1MAov3-AugAwMc
Subject: Re: [TLS] Should we require compressed points
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: Tue, 28 Oct 2014 16:26:10 -0000

On 28/10/2014 15:52, Viktor Dukhovni wrote:
> 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.
> 
Yes, I didn't see his suggestion when I posted, but now I agree it looks like
the best way to go.

Manuel.