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

Bryan Ford <> Sat, 21 May 2016 14:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34BF612D10B for <>; Sat, 21 May 2016 07:36:14 -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 lmwl24mCVaHG for <>; Sat, 21 May 2016 07:36:12 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 48BB212D0FF for <>; Sat, 21 May 2016 07:36:12 -0700 (PDT)
Received: by with SMTP id n129so18983763wmn.1 for <>; Sat, 21 May 2016 07:36:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=nbf7iaSY/qMvJYBAJtlXYecBb/8TKBEmRbQQKe7Vgp0=; b=I91hoNXSOy+ePzdKl0V5j8JBCmEPPLl7FzLlqy9kk0PNEQaIassrJCboNxwlbhN9Jp EtRzhUn9XtrSldyiuExqEJNDHwZ6vM4mc9OhQcmeraf2szBr30xpvXG+k01phidT2Cgl E7q6lfTW1lUiyAHcWo7XHEaTN6qSBy49HDrKKkr4vcOo+7eusD0T3XPhTFYBlV9DkkWB E6TjEJO6i9JI/ykLRyiKS4Fnun/xRqgDi79Me3x1SPlamruczBRxx16xNSSk1dB1ehZe 6L4dDHTCL/6z5yAprFzUlKdRk+3NGv8beyfErfk+O12qYwdshOUfH6rmxn7Y3xCa/AjM TAPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=nbf7iaSY/qMvJYBAJtlXYecBb/8TKBEmRbQQKe7Vgp0=; b=AL4jyC4VlWnL2egshmIVoCiPbEsawAMNZr1DnzK5Lmh11v4RzRPM+NSKCkoWljLtal nQz5Nt0ky7DjXGqdHEZF9bWRLNAgdVUQPGcLi/Z6PLq0NFxjPU5f+om1zn0s19iuNKm2 RMOED8osLDp7g+Xl/hBSUoN5lk0B5YSQAjxUIhTanTkcWUKciTI8ck0gWzfkiUouzjPW ljBxsM85J4xaEuE5gS3Xxxj6ly6XrmiX3I9gcKNi5OiqfzgcIIH7X1+pXiLH7MOZnIDL Hrxwon6vDKVaVZmc71Zx9i7JsJ5ztJFFUvs3/1e/IJuKwTjh7mp0DtIP7LzgsglGUOI/ /H6w==
X-Gm-Message-State: AOPr4FVQKd3Ffe0zjc2z58PJYyzazE9fwLrIsymJAFQDoTvhN04/+Vo4bEYtCdqR4Gm1ZQ==
X-Received: by with SMTP id 79mr9178981wmy.42.1463841370772; Sat, 21 May 2016 07:36:10 -0700 (PDT)
Received: from ( []) by with ESMTPSA id f8sm25291092wjm.13.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 21 May 2016 07:36:09 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_307395E8-6E25-48B6-B09E-7D790F5FC6C3"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Bryan Ford <>
In-Reply-To: <>
Date: Sat, 21 May 2016 16:36:07 +0200
Message-Id: <>
References: <>
To: "D. J. Bernstein" <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Resent-To: <>
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, 21 May 2016 14:36:14 -0000

Hi Dan, 

On May 21, 2016, at 3:57 PM, D. J. Bernstein <> wrote:
> Bryan Ford writes:
>> While the same domain-separation benefit can always be achieved by
>> just prefixing the message, having an explicit context parameter in an
>> API forces the software developer who’s calling that API to see it,
>> and think “do I need to pass something there? what? should I ask a
>> colleague?”
> And so they copy and paste code from somewhere else, or (if they're in
> control of both ends) try the empty string, which works, the same way
> that most protocols built on top of DNS are identified in DNS as "TXT”.

Even if they just to that, then that’s better than if there was no context parameter.  The subset of developers who just copy-and-paste a “TXT” context parameter for one set of applications (likely related, since they’re more likely to copy-and-paste from a similar application than a completely unrelated application) will be domain-separated from the subset of developers who copy-and-paste a “FOO” context parameter in another set of applications, and from the developers who copy-and-paste a “BAR” context parameter in a third class of applications.  Whereas without the context parameters, there will be no domain separation and the risk of signature confusion is strictly worse than if there were no context parameters.

Further, in any IETF-defined protocol in the future that specifies that the context parameter must be “FOO”, any demonstrably interoperable implementation of that protocol will have to use that context parameter, because an implementation that doesn’t will fail to interoperate in a completely obvious way.  Thus, if the IETF defines the Foo protocol to use “FOO” as the contexts in its signatures, and the Bar protocol is defined to require “BAR” to be used as the context in its signatures, then the FOO and BAR domains will effectively be enforced via the IETF process, leaving it not even up to the application developers.  Of course developers of different Foo implementations will probably still copy-and-paste code that creates “FOO”-context signatures from other implementations of the Foo protocol, but that’s fine.

> How do you imagine most programmers being successfully pressured to
> create a new "context" whenever the message semantics change: library
> revisions, for example, or state modified by previous messages?

I never suggested that, and I don’t remember seeing anyone else here suggesting that.  In fact I don’t remember hearing anyone suggesting that programmers be “pressured” to do anything in particular with contexts.

> If you think you're solving the fundamental cross-protocol security
> problems that I described in "Side inputs to signature systems, take 2",
> then let me suggest that you follow up in detail to that message. I see
> your proposed bottom-to-top API revision as a distraction from the core
> task of developing secure message semantics.

Looking up the message you’re referring to, it looks to me like you’re way overthinking this.  

Yes, you could turn the context into a hierarchical filesystem-like namespace if you want, e.g., with “FOO/V1” versus “FOO/V2” being V1-type versus V2-type signatures for protocol or application FOO.  One of the nice things about variable-length strings is that they’re automatically composable, up to the 255-byte limit.  Protocol developers - or other IETF WGs that need to use signatures and need to specify what the “context” should be for those signatures - are free to consider fancy hierarchical schemes like that if they want.  Or not.  The EdDSA RFC need not and should not mandate that or any particular scheme for choosing context strings.  Leave that to those who build applications or protocols that use signatures.  If you don’t want context strings at all in your next application or protocol, then fine, don’t use them (i.e., use the empty string).  No Context Police SWAT team is going to bash down your door and haul you in to the face the Inquisition.

Nobody that I see is proposing that contexts “solve” any “fundamental cross-protocol security problems”.  All they are intended to do is add a bit of (weak, but preferably redundant) protection against certain classes of message-confusion blunders at a software engineering level.