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

[Bryan Ford <[e-mail]>]

Hi Dan, 

On May 21, 2016, at 3:57 PM, D. J. Bernstein <[e-mail]> 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.

Bryan