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

Eric Rescorla <ekr@rtfm.com> Mon, 15 June 2015 13:48 UTC

Return-Path: <ekr@rtfm.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 2CD3E1A8A4D for <tls@ietfa.amsl.com>; Mon, 15 Jun 2015 06:48:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 yYPTIT9Yed-P for <tls@ietfa.amsl.com>; Mon, 15 Jun 2015 06:48:35 -0700 (PDT)
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (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 EC3D41A1A2F for <tls@ietf.org>; Mon, 15 Jun 2015 06:48:34 -0700 (PDT)
Received: by wgbhy7 with SMTP id hy7so36169700wgb.2 for <tls@ietf.org>; Mon, 15 Jun 2015 06:48:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fBBt4b/75Yp9Hb8jiZdukkLQzN2GyyXAdwXXU1rOrpo=; b=bGHWyogL0hsQ8til4scGrEzZ/iK5wWLrmg+xHNsAeN17yMDqqFI+pFZDIjA3H22s2i wwVz6YENsputNm75QRwAaUiGROtFrD/bsXC/YFR+HoeO9eqfk20C+UI3NJgvNlLKncsM ijgPi3aDPbB+6ijEr00znP/f5IkjttuWCJWoYaLOPWEk/u0oX+82QgbIQf9eUjwKA6tj FFIGMtWTx2anjrIkwWtYeR8ScKFhmpGePxcorsv/7PCMRRxc+Y51OLHelhrOAIFbuHPZ zc5dO88ok26rRhFLPYEHkj4YEWunAVUwAwvgXHmruDTRuYahXXIS9ZYdvrzRGtLf4jxM lhpQ==
X-Gm-Message-State: ALoCoQlhqwWUr2TPlVqanZeuT1BXXbtjvHFyzHzzV6fbhUvKXmg6/FZIZU6Q/tHca+VcHN5TXwN4
X-Received: by 10.194.79.225 with SMTP id m1mr52852725wjx.8.1434376113707; Mon, 15 Jun 2015 06:48:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.225.14 with HTTP; Mon, 15 Jun 2015 06:47:53 -0700 (PDT)
In-Reply-To: <20150615132919.GA28329@LK-Perkele-VII>
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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 15 Jun 2015 06:47:53 -0700
Message-ID: <CABcZeBPfO6jOgNKxGQhJZrGQzjw50JsCMXAAgz+njP5wRx8a1Q@mail.gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Content-Type: multipart/alternative; boundary=047d7b10c903bb6fc805188eb662
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/dHINEm5un7jd13WVnM2XOtuZUzo>
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 13:48:37 -0000

On Mon, Jun 15, 2015 at 6:29 AM, Ilari Liusvaara <
ilari.liusvaara@elisanet.fi> wrote:

> On Mon, Jun 15, 2015 at 01:03:45PM +0000, Viktor Dukhovni wrote:
> > On Fri, Jun 12, 2015 at 01:43:25PM -0700, Martin Thomson wrote:
> >
> > > > "Servers MUST NOT select an ECDHE_ECDSA ciphersuite if there are no
> > > > common curves suitable for ECDSA."
> > > >
> > > > You mean MUST NOT select ECDSA certificate? Because TLS 1.2 rules
> > > > seemingly allow selecting ECDHE_RSA ciphersuite with ECDSA
> > > > certificate.
> > >
> > > This seems right to me.  The point here is that when a named_curve (or
> > > named_group) identifies 25519, then it can't be used for ECDSA.  25519
> > > is always OK with an _RSA_ suite.
> >
> > It seems that provided there's also a named_curve for ECDSA
> > that matches the certificate, then one might use 25519 for a key
> > exchange that is signed with ECDSA.
> >
> > If both are supported I don't see why this combination should be
> > excluded.  What problem does the exclusion solve?
> >
> > If 25519 ECDH is faster and safer than with ECDSA why not use it
> > even with servers that sign the parameters with ECDSA?
>
> The problem is that clients that support 25519 ECDHE might not
> support any curve usable for ECDSA.
>
> And even if they did, they are very unlikely to support 25519
> ECDSA.


Taking a step back, RFC 4492 doesn't contemplate the case that you could
use curve X for (say) ECDHE and not for signature, though it *does*
allow for you to use different curves:

   NOTE: A server participating in an ECDHE-ECDSA key exchange may use
   different curves for (i) the ECDSA key in its certificate, and (ii)
   the ephemeral ECDH key in the ServerKeyExchange message.  The server
   must consider the extensions in both cases.

So the problem is that the signal that RFC 4492 contemplates is not
sufficiently
rich to support this case. However, it's obviously desirable that you be
able to
do Curve25519 ECDHE while still doing P256 for signature.

It seems that there are two potential solutions here (assuming that the CFRG
actually comes up with a Curve25519-based signature scheme).

1. Decide that it's not ECDSA
2. Pretend that there are two curves: Curve25519_kex and Curve25519_sig.

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.

-Ekr