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

Daniel Kahn Gillmor <> Sat, 23 April 2016 19:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B0B2312D136; Sat, 23 Apr 2016 12:54:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yV9tGhMWcyb4; Sat, 23 Apr 2016 12:54:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 63C2B12B051; Sat, 23 Apr 2016 12:54:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 41E74F991; Sat, 23 Apr 2016 15:54:07 -0400 (EDT)
Received: by (Postfix, from userid 1000) id E15D61FF9D; Sat, 23 Apr 2016 15:54:06 -0400 (EDT)
From: Daniel Kahn Gillmor <>
To: Simon Josefsson <>
In-Reply-To: <>
References: <> <>
User-Agent: Notmuch/0.21+128~g620f892 ( Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Sat, 23 Apr 2016 15:54:03 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <>
Cc: Robert Edmonds <>,,, Ondře j Surý <>, 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: Sat, 23 Apr 2016 19:54:10 -0000

On Sat 2016-04-23 03:23:15 -0400, Simon Josefsson wrote:
> Further, introducing this tweak late in the process appears unfortunate.
> We are having serious trouble shipping documents people have been
> waiting for as it is.  Redefining what they will get this late in the
> process is harmful.

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.

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.

Section 4 there now says:

   EdDSA signatures in this scheme use the 17-octet context label
   'DNSSEC SIGNATURE\0' (where \0 represents a zero-valued octet).
   (Note: Only Ed448 has the Context specified.  Before publishing the
   final draft we need to specify what to do with Ed25519 Context.)

> 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; or it
will discourage people from even trying to distinguish between domains
that do use Ed25519 ("don't bother, unless you use Ed25519ctx instead").

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