IETF Logo Mail Archive

Re: [TLS] Should we require compressed points

Bodo Moeller <bmoeller@acm.org> Tue, 28 October 2014 10:49 UTC

Return-Path: <SRS0=TF6k=7T=acm.org=bmoeller@srs.kundenserver.de>
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 2BB251A1B7A for <tls@ietfa.amsl.com>; Tue, 28 Oct 2014 03:49:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level:
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 egLb5PPPlE3k for <tls@ietfa.amsl.com>; Tue, 28 Oct 2014 03:49:21 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00A821A1B79 for <tls@ietf.org>; Tue, 28 Oct 2014 03:49:20 -0700 (PDT)
Received: from mail-yk0-f170.google.com (mail-yk0-f170.google.com [209.85.160.170]) by mrelayeu.kundenserver.de (node=mreue005) with ESMTP (Nemesis) id 0MJYJr-1Xg3Wv1KeJ-003A2n; Tue, 28 Oct 2014 11:49:18 +0100
Received: by mail-yk0-f170.google.com with SMTP id 19so158566ykq.29 for <tls@ietf.org>; Tue, 28 Oct 2014 03:49:16 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.36.110 with SMTP id v74mr2019896yha.164.1414493356968; Tue, 28 Oct 2014 03:49:16 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Tue, 28 Oct 2014 03:49:16 -0700 (PDT)
In-Reply-To: <CABcZeBPuvAde9iJMHQV59J6-KJU=A2m9LzosmQWoCspmWeFiJg@mail.gmail.com>
References: <CABcZeBMqdwWTFxGAqaC9PqhzbgZM5yOf2TTq7pVCjyw_X+3Zkg@mail.gmail.com> <1799fe49d54b4d43acc26778b9265c8a@BL2PR03MB419.namprd03.prod.outlook.com> <CABcZeBPuvAde9iJMHQV59J6-KJU=A2m9LzosmQWoCspmWeFiJg@mail.gmail.com>
Date: Tue, 28 Oct 2014 11:49:16 +0100
Message-ID: <CADMpkc+buPR4fAS3D4n3GBn7EPkPGTGa1=aDs-pLvQp6xtuFzg@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="089e0160c4781470ac05067966e5"
X-Provags-ID: V02:K0:5D+vyPrlWqk8eI13XANRlf4R2Vcswj7P43c2WmbdAGq 1eHsaQ16eo0iOEU5vw8Dm1JRYKeCWo7e5f8ArzsJJw1RZaTnlh 6r8mXJEIF7tldum3BsDPqvQ1u+xie3vd/D+5ZKTLslvzvvr/de hYAI0CgXPLwql80FXWjqfMGU9cQfAiqrGw0HcsCXpkqog/zl4N h67y76DtzmBkMxCwv+R6HmR5HlcUZLgNUfBKzcxwnIrrjbtFY7 axGUF0fpbJ5ZA+77Ko0M5PCPWoDSjzZ1fzMNiPjanLnjmzoBZA Emux9b5pROoKjuIyH9ol46PGk34+c5PNODFcd6UQnhsr0jGkvE knBKzQsMqlmr3sQGWkZzTLtpwHFABQxBVLx84F6MI8tF4SG/P/ Cac4wg5dnBqb43TDfnL3A79wWSQajPdFxk6A4J3emh8dMy6bST mC/fU
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FUMUhodAcA1nnsjc-Ocoboxpooc
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: Tue, 28 Oct 2014 11:12:37 -0000

Eric Rescorla <ekr@rtfm.com>:

Really what I want is to get rid of point negotiation, because it's yet
> another
> point of complexity and it's not universally implemented anyway. Given that
> people seem to think that compressed points are better, I figured that was
> the way to go. If people prefer to just require uncompressed points (at
> least for the existing X9.63 curves) I could certainly live with that.
>

RFC 4492 requires support for uncompressed format (and uncompressed format
is assumed if the supported point formats extension is omitted), so
switching to compressed format for the existing curves in the next protocol
version appears to be asking for trouble.

Deprecating the supported point formats extension isn't a bad idea, but
then if we want to support compressed format for some of the current
curves, the right way to do that would be to define new NamedCurve values
for these.

Bodo

v2.23.0 | Report a Bug | By Email