Re: [TLS] Should we require compressed points

Martin Thomson <martin.thomson@gmail.com> Wed, 22 October 2014 18:47 UTC

Return-Path: <martin.thomson@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 09B8F1ACFC9 for <tls@ietfa.amsl.com>; Wed, 22 Oct 2014 11:47:14 -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 K2rPrN3-1DDO for <tls@ietfa.amsl.com>; Wed, 22 Oct 2014 11:47:12 -0700 (PDT)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961EA1ACFCD for <tls@ietf.org>; Wed, 22 Oct 2014 11:47:10 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id mc6so3512596lab.2 for <tls@ietf.org>; Wed, 22 Oct 2014 11:47:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MJVPHyGDQi1haQFuD0Xt8iXR7D6GUqjuedYrlgDDh+w=; b=04u1mKUZaRZpPV1D/HETYtm+JUQ1a36YGIWZwNBv7PsIdLfnfhTo4CJqFg490dQ5yH RXyBNZHaBTHMGjMCQbnRRUYwAcIoxYyNEgcO4rNb71chd+OZ+8TuNGtLbHxAcDvQHP3n 2W7q9gxuw9V4dZylBHt7XppuZLOyKk8VJWT242LP6CogHbXmH5oyZpa//jwG+lgBf668 asxQBrRsuWX5JL2Lqera0sUFBNu2+owZcX9f/fU4ezOW2c9dwfhvrn0rbhD3tX+9oGx9 ORrrg12ah9+ZFwaX50VND8BSCT1tXyFw8r3+qXWApVIPzFslSUS3jdoRNRYJqnIQY6Yu y80A==
MIME-Version: 1.0
X-Received: by 10.152.116.68 with SMTP id ju4mr43426758lab.13.1414003628875; Wed, 22 Oct 2014 11:47:08 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Wed, 22 Oct 2014 11:47:08 -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: Wed, 22 Oct 2014 11:47:08 -0700
Message-ID: <CABkgnnUa8LKAF8e_0HWZL-Y7f5U=rEY_PqyVc6q4+Er2ATYvgg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fQZTb2kTbUicPpoU_F2Mjnxmfew
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: Wed, 22 Oct 2014 18:47:14 -0000

On 22 October 2014 11:26, Eric Rescorla <ekr@rtfm.com> wrote:
>> What are the reasons for getting rid of uncompressed points?
>
>
> 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.

Yep, and I'll note that 32 octets isn't a trivial amount of space in a
handshake.  We're particularly space constrained here.  If that's 32
octets more of application data I'd have available, I suspect that
another compressed HTTP/2 request - or a good proportion of one -
could fit in that space (for a 0 RTT mode in particular).