IETF Logo Mail Archive

Re: [TLS] I-D Action: draft-ietf-tls-curve25519-00.txt

Martin Thomson <martin.thomson@gmail.com> Mon, 15 June 2015 16:59 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 3F5271A90E9 for <tls@ietfa.amsl.com>; Mon, 15 Jun 2015 09:59:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_15=0.6, 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 1lOW2XXu-OZS for <tls@ietfa.amsl.com>; Mon, 15 Jun 2015 09:59:51 -0700 (PDT)
Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104341A90F1 for <tls@ietf.org>; Mon, 15 Jun 2015 09:59:35 -0700 (PDT)
Received: by ykaz81 with SMTP id z81so61599831yka.3 for <tls@ietf.org>; Mon, 15 Jun 2015 09:59:35 -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=iGC9wQKR1erB8Pmm6TPMl52khQVLP3JboZ6Rmz5g+sE=; b=fK2MdM9VvyeCcj5V8eVQ4CU4snSdXaPUGU7y3fZ9adx5BPRIWAisiTOtOMgvRM1nXK 2y/kgJsecroGaWpucWRTDTlbQ15K92frs3Yrcv8TA02a5KQL0IvXCfj7UIAfJj6zsgoV uocHXBBesyOsgoy2jmcmfleVE4TpND5JvoWoOEOOc7mh/deNcRaghcjE+hziAnBUpZQU TA7CtEQmUfSTnXX/JMuFah1fYmX0mMH1FjyYGaiF/jdw0TznY864reyDxbiXD9m/LRKk oCDxGRBAk/+yhQwwTKiJzFviH0TuR0URRXVQd6TFlNOZbOSG8hEhph01U7WnAyvOVRcY jHBQ==
MIME-Version: 1.0
X-Received: by 10.13.226.75 with SMTP id l72mr36359593ywe.89.1434387575459; Mon, 15 Jun 2015 09:59:35 -0700 (PDT)
Received: by 10.129.110.138 with HTTP; Mon, 15 Jun 2015 09:59:35 -0700 (PDT)
In-Reply-To: <CABcZeBPfO6jOgNKxGQhJZrGQzjw50JsCMXAAgz+njP5wRx8a1Q@mail.gmail.com>
References: <20150612180230.4804.45802.idtracker@ietfa.amsl.com> <20150612195654.GA9401@LK-Perkele-VII> <CABkgnnVh6P=pkmdQJcsDgVr1=cYZ7darDjTaKnq_-d2vmB970Q@mail.gmail.com> <20150615130345.GJ14121@mournblade.imrryr.org> <20150615132919.GA28329@LK-Perkele-VII> <CABcZeBPfO6jOgNKxGQhJZrGQzjw50JsCMXAAgz+njP5wRx8a1Q@mail.gmail.com>
Date: Mon, 15 Jun 2015 09:59:35 -0700
Message-ID: <CABkgnnWk=3r9pix_5CZGRyTyx4q=F5GHb8-pktaVQ0huUd1u0g@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/t-wnljMHZrbJMNeAdEAW71swfQg>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-00.txt
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: Mon, 15 Jun 2015 16:59:52 -0000

On 15 June 2015 at 06:47, Eric Rescorla <ekr@rtfm.com> wrote:
> In the latter case, implementors of this draft would just advertise
> Curve25519_kex
> and future implementors of the signature draft would  advertise
> Curve25519_sig.
> Note that we don't have to decide this questions now, since the issue does
> not yet
> arise. We can just state that advertising Curve25519 doesn't mean that you
> should do ECDSA with it.

And I'd be happy with this outcome too.  That is, we might decide
later to reuse the code point.

Of course, I'd still argue not to do the overload, based on the
potential for implementations to support one and not t'other.

v2.20.3 | Report a Bug | By Email