Re: [TLS] Should we require compressed points

Manuel Pégourié-Gonnard <mpg@polarssl.org> Sat, 01 November 2014 17:21 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 2358B1A8A0C for <tls@ietfa.amsl.com>; Sat, 1 Nov 2014 10:21:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level:
X-Spam-Status: No, score=0.397 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, 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 dRNc8C-TpuOL for <tls@ietfa.amsl.com>; Sat, 1 Nov 2014 10:21:25 -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 A058A1A89EF for <tls@ietf.org>; Sat, 1 Nov 2014 10:21:25 -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:CC:To:MIME-Version:From:Date:Message-ID; bh=YicEfaddijpJXGqmM2iq/4SFt6yRsj7y2R98n2P+l7k=; b=jTO8aCaxGyPLyvQ+mWlhsrYDZdBL5Uu5uVdmW17sKZ9IFUbVn2vQnfjSj5oBqF453MB98F5EpnXN3LL4pKnI992GrXEJrQv0LrU9hzqI9XrH4WXWUo/UDivI1/tnN8o3gBKg06MgZs20F18R89YvSqx8Rzz/lZ7921aU+3amhMw=;
Received: from mna75-11-88-161-199-191.fbx.proxad.net ([88.161.199.191] helo=[192.168.0.12]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1XkcMX-0006cd-PD; Sat, 01 Nov 2014 18:21:18 +0100
Message-ID: <54551692.2070905@polarssl.org>
Date: Sat, 01 Nov 2014 18:21:22 +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: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, Eric Rescorla <ekr@rtfm.com>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D6102@uxcn10-5.UoA.auckland.ac.nz> <CABcZeBOWR4BVy0e3TY3FVB8wqOwrUgD6OfHLTJS_iXUZv30CsA@mail.gmail.com> <544F635D.2000309@polarssl.org> <20141028145223.GQ19158@mournblade.imrryr.org> <544FC339.8010605@polarssl.org> <CABcZeBPctqdSia7tJ5F9s42wAYq5mWL06qjCPUxdWFVL-BSKHw@mail.gmail.com> <20141031183146.GA12592@LK-Perkele-VII>
In-Reply-To: <20141031183146.GA12592@LK-Perkele-VII>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.161.199.191
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/8QBxHjVjsOsz89r0b0kJgxubhmU
Cc: "tls@ietf.org" <tls@ietf.org>
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: Sat, 01 Nov 2014 17:21:27 -0000

On 31/10/2014 19:31, Ilari Liusvaara wrote:
> On Fri, Oct 31, 2014 at 10:34:52AM -0700, Eric Rescorla wrote:
>> This discussion seems to be settling, so I've prepared a pull request
>> that implements Bodo's suggestion:
>>
>> https://github.com/tlswg/tls13-spec/pull/86
>  
> I think 8.1.2 (ECDHE premaster secret calculation) should be modified
> as well, to specify using the fixed wire encoding of selected group for
> premaster secret.
> 
Just to be clear: this would change the way the PMS is computed for the existing
curves, right? I'm not opposed to it, I just want to make sure we're on the same
line.

> This is to avoid problems with more "odd" encodings.
> 
I think this is indeed a very desirable outcome, that is achieved by your proposal.

> Note that 8.1.1 does not quite match that beheviour, since it specifes
> leading zero octets to be stripped (whereas DHE "element" encoding
> doesn't seem to specify if zeroes are stripped or not)
> 
I think it makes sense to accept non-canonical representation of DHE elements as
long as it's not ambiguous (be liberal in what you accept), while for the PMS
it's necessary to be strict in order to ensure interop. But I wouldn't be oppose
to something like "DHE elemens MUST be encoded without leading zeroes, but
implementations MAY accept leading zeroes in their encoding".

Manuel.