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

Watson Ladd <> Sat, 23 April 2016 21:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23E6F12B02C; Sat, 23 Apr 2016 14:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bf48AE3Njqbx; Sat, 23 Apr 2016 14:25:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 699BF12B01C; Sat, 23 Apr 2016 14:25:17 -0700 (PDT)
Received: by with SMTP id t129so175739286vkg.2; Sat, 23 Apr 2016 14:25:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=4Jeb8d4EUX/C9VKcSf+Zi9f/7aK24xLsBHd96ToCkF0=; b=Jeo7bdyUmyl9Up2J/n1kX+6F2PMuANNqP+QjvNIdC0lcF7zzCiohr6aD0Q9A7qCXzl 5q14MPpLFnkNnljvgbjBxo3vZ1TcMpzIwMm0cCDwkGu2ermesoX5HCIFXNH9Pu2kWPL0 W5KXIYI2S8RvsNX5FjR1gh0cDm0KKCRrMyWqVidbdLuSdE2VEtzMOo2VMtaK771A8+kL UMuIycZ5Ov6QSR+OD/PM5oPEIffNG9dT28QINcqq+wz2fYtELUu4NGlsdMh5l2lptmLF OrGNvbCeq/gHw9nrg84mCCKrzNDuIFT9C/CC7LJ88IW3JiJYgH/8ee+Sq1QZHQ+pHPj4 FRCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=4Jeb8d4EUX/C9VKcSf+Zi9f/7aK24xLsBHd96ToCkF0=; b=mTT5RwDtKjuoW15yo2Jh6gj/qcaylaVb7KsEhrtxmSF20URqi8HnZ0RjyaFouGaSPX 9f1dAQknwajwp9Ql6SHShZSroIUtkaTL3NXNfjw5M6GuoU/Ia151TwbiLJGRdA0VxG6L NNI17YJt65gT2WgUsL7rvmFzef/+qrIkCD/D+Jb1lGV0sRiv1geHhyFC6AHdULXaiu3F 9iRkjnSpr1Wz0a3OS1fppbhZIp3eikbn6dfaEnyu3s9/BcfBfGhWr0H3hnwx/sDrPr2f pxih5AzlR/O1CkCKJIh99p/1uKNqvIhPVsCtE/+R3APKaynQqncJiPKKWgAWw4bKYxfz CFMw==
X-Gm-Message-State: AOPr4FXF++Le5T6x2baITAudIxonVIaFZGsF4FwvVRWZzF508/wHuL5k21TuLsSTdGWe6ts9iHl/wFOmSzbMRQ==
MIME-Version: 1.0
X-Received: by with SMTP id 59mr13592993uas.16.1461446716397; Sat, 23 Apr 2016 14:25:16 -0700 (PDT)
Received: by with HTTP; Sat, 23 Apr 2016 14:25:16 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Sat, 23 Apr 2016 14:25:16 -0700
Message-ID: <>
From: Watson Ladd <>
To: Daniel Kahn Gillmor <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: Simon Josefsson <>, Robert Edmonds <>,, "" <>, Ondřej 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 21:25:19 -0000

On Sat, Apr 23, 2016 at 12:54 PM, Daniel Kahn Gillmor
<> wrote:
> 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
> does.

Systems actually deployed today are actually using signature systems
that don't have the context argument. The whole argument that we need
to reconsider what signatures are is fine: but it shouldn't stop us
from introducing a new signature scheme that meets the standard

>            --dkg
> _______________________________________________
> Cfrg mailing list

"Man is born free, but everywhere he is in chains".