IETF Logo Mail Archive

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

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 15 June 2015 13:03 UTC

Return-Path: <ietf-dane@dukhovni.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 2497E1B35FD for <tls@ietfa.amsl.com>; Mon, 15 Jun 2015 06:03:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] 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 GcQlsJWjaIi8 for <tls@ietfa.amsl.com>; Mon, 15 Jun 2015 06:03:47 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCD1E1B35FC for <tls@ietf.org>; Mon, 15 Jun 2015 06:03:47 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EB887284B58; Mon, 15 Jun 2015 13:03:45 +0000 (UTC)
Date: Mon, 15 Jun 2015 13:03:45 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150615130345.GJ14121@mournblade.imrryr.org>
References: <20150612180230.4804.45802.idtracker@ietfa.amsl.com> <20150612195654.GA9401@LK-Perkele-VII> <CABkgnnVh6P=pkmdQJcsDgVr1=cYZ7darDjTaKnq_-d2vmB970Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABkgnnVh6P=pkmdQJcsDgVr1=cYZ7darDjTaKnq_-d2vmB970Q@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/A59eHfugbEhTR-FTFM3yN3WIvYs>
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
Reply-To: tls@ietf.org
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:03:49 -0000

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?

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email