Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519

Simon Josefsson <> Fri, 06 May 2016 07:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7218612D0F2; Fri, 6 May 2016 00:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rf7YJTo6kYo0; Fri, 6 May 2016 00:04:16 -0700 (PDT)
Received: from ( [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC52912D4FF; Fri, 6 May 2016 00:04:15 -0700 (PDT)
Received: from ([]) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id u4673moV030093 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 6 May 2016 09:03:49 +0200
From: Simon Josefsson <>
To: Daniel Kahn Gillmor <>
References: <> <> <>
OpenPGP: id=54265E8C; url=
Date: Fri, 06 May 2016 09:03:47 +0200
In-Reply-To: <> (Daniel Kahn Gillmor's message of "Sat, 23 Apr 2016 15:54:03 -0400")
Message-ID: <>
User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
X-Virus-Scanned: clamav-milter 0.99 at
X-Virus-Status: Clean
Archived-At: <>
Resent-From: <>
Cc: =?iso-8859-2?Q?Ond?= =?iso-8859-2?Q?=F8ej_Sur=FD?= <>, Robert Edmonds <>, Benjamin Kaduk <>,,
Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 May 2016 07:04:19 -0000

Daniel Kahn Gillmor <> writes:

> My goal in raising this is not to delay the process further, but to at
> least clarify for future readers why the interfaces for Ed25519 and
> Ed448 differ by a "context" argument, and to give some form of
> implementation guidance to people who want to use that argument while
> being able to use both signature schemes.

Hi Daniel, all,

I agree that is a good goal -- if you can think of text to explain this
difference I would support that it is added.

> A recent example is
>, which
> defines DNSKEY records for both Ed25519 and Ed448.  I spoke to the
> authors about using a context label to avoid RRSIGs from being re-usable
> in non-RRSIG contexts.

Instead of introducing complexity (i.e., contexts), I suggest that you
recommend to not re-use the same key for different purposes!

Key re-use for different purposes is the fundamental problem as I see
it.  The idea behind context may have good intentions, but I believe
contexts is only a band-aid for the problem of cross-domain key-reuse,
and I believe that overall contexts introduce more harm than they
address.  I believe it is better to address the problem at its source.

>> So here is a suggestion.  Write a document describing a Ed25519-variant
>> called Ed25519ctx.  I would help work on it.  For those implementations
>> that are interested in using Ed25519ctx (which are they?), try to get
>> them aligned behind the document.  If there are, say, two different
>> protocols that have a desire to use contexts, I would believe that there
>> shouldn't be a problem getting the document published as an RFC.
> This will only further delay systems that want to use Ed25519

How so?

> or it will discourage people from even trying to distinguish between
> domains that do use Ed25519 ("don't bother, unless you use Ed25519ctx
> instead").

My point is that it is a bad idea to attempt to distinguish between

> As i wrote in my mail that started this thread, i'd be fine with just
> the addition to the security considerations explaining the distinction
> between the primitives, if that would get the draft out the door more
> promptly.  I don't want this to drag on any longer than anyone else
> does.

Thanks -- and I agree text like that would be good.  Sorry I didn't
catch this in your first email, I read it as a request to add contexts
to Ed25519.