Re: [TLS] EDDSA/Curve25519 identifiers: Was Re: AES-OCB in TLS

Nico Williams <nico@cryptonector.com> Thu, 11 June 2015 03:20 UTC

Return-Path: <nico@cryptonector.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 B9C761A8AC7 for <tls@ietfa.amsl.com>; Wed, 10 Jun 2015 20:20:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.233
X-Spam-Level:
X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 zeAT5EwtsBMf for <tls@ietfa.amsl.com>; Wed, 10 Jun 2015 20:20:22 -0700 (PDT)
Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CC71C1A8ACC for <tls@ietf.org>; Wed, 10 Jun 2015 20:20:22 -0700 (PDT)
Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id AB13C31809F; Wed, 10 Jun 2015 20:20:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=KJRasAXopaZVw5 QFF+SgXn+NSfg=; b=o+ou9kAdpW7a9v3zIB9gT/aBQ0l4GJEeMUTevIKOVVExYI z/XiVbm5x2lx14Z3bEitzEm47dT3TxRy2HQEpyZddgOF156AMc3y3tXEg937T1kg k1VpHbHQ3cv5Wx3z1CccR5PiLcFxI7YhuPpiC9M7U/z7Ski01wrmejVmjah/M=
Received: from localhost (unknown [172.56.18.136]) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPA id 25194318095; Wed, 10 Jun 2015 20:20:22 -0700 (PDT)
Date: Wed, 10 Jun 2015 22:20:21 -0500
From: Nico Williams <nico@cryptonector.com>
To: Michael StJohns <msj@nthpermutation.com>
Message-ID: <20150611032020.GB4007@localhost>
References: <556C4ACD.9040002@azet.org> <CABcZeBNsYmto4F-J0mFoxcq-qfL=NJrvDu67fyY9bpBmRp16mQ@mail.gmail.com> <556C51FC.807@azet.org> <20150601125302.GA19269@LK-Perkele-VII> <556C9AF4.7030607@nthpermutation.com> <87r3pp3803.fsf@latte.josefsson.org> <55787375.7040808@nthpermutation.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <55787375.7040808@nthpermutation.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/h6a6G3phCfxbXZs7H0KNED1uY4s>
Cc: Simon Josefsson <simon@josefsson.org>, tls@ietf.org
Subject: Re: [TLS] EDDSA/Curve25519 identifiers: Was Re: AES-OCB in TLS
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: Thu, 11 Jun 2015 03:20:23 -0000

On Wed, Jun 10, 2015 at 01:27:17PM -0400, Michael StJohns wrote:
> On 6/5/2015 10:06 PM, Simon Josefsson wrote:
> >Are you saying it would be useful to also specify certificate formats
> >for Curve25519 ECDH keys?
> 
> Sorry - I missed this in the pile.
> 
> And yes for Curve25519.
> 
> Here's my thoughts:
> 
> [...]
> 
> The nice thing about this scheme (It's called a C(2,2) scheme in
> NISP SP800-56A parlance), is that you don't need to sign anything
> during a key agreement handshake.  You still need traditional
> signature schemes over the certificates, but you don't actually need
> them in the handshake.

RSA key transport was nice because it was faster than DH + signatures.

Now that PFS matters that consideration goes the way of the dodo.  It's
got to be key agreement + authentication, which means either key
agreement with signatures, or two key agreements.

(Using DH with fixed public keys goes back to the invention of DH
itself, and this was deployed way back when.  E.g., AUTH_DH.  This is
why PKIX supports key agreement certificates.  Combining DH for
authentication with DH for PFS is an obvious idea.)

And besides, with ECC and curves like Curve25519, *two* ECDH exchanges,
one of which has a certified public key on the server side (the other
being ephemeral, for some value of "ephemeral"), can go faster than one
signed ECDH exchange.  How much, if at all, may depend on what curves
and implementations.

> There are other schemes where one side only has ephemeral keys (e.g.
> client without cert) where this still works - you end up with:

Right, and which would be the common case on the Internet.

> This just works with the existing EC Prime and F2M curves as the key
> pairs can be used with both ECDSA and ECDH.

Is that safe?

> In any event, going ahead and creating a certificate format for
> Curve25519 at the same time you do ED25519 probably makes sense
> given the two algorithms are family members and appear to share a
> representation.

Sure, but doing it separately works too.  Whatever makes the spec go
faster.

Nico
--