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

["D. J. Bernstein" <[e-mail]>]

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".
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?

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.

We already have too many file-type systems. Most of them were designed
out of complete disregard for previous work; we definitely don't need
more of these. Efforts to define semantics via oversimplified metadata
tags (DOS file types, for example, and MIME types) have always ended up
being supplemented by more flexible mechanisms to define semantics
inline (MP4, for example, and XML). People build software-dispatch
mechanisms around metadata tags and then end up having to build more
flexible software-dispatch mechanisms to handle subtypes declared
inline. Programmers are constantly fighting multiple API layers for
something that could and should have been handled with just one layer.

>From a security perspective there's even more importance to specifying
semantics clearly; it's even more clear that these semantics depend on
application-specific dynamic context; and we _definitely_ don't want
unnecessarily complicated APIs. Separate tags have historically proven
to be inferior to inline mechanisms in all of these dimensions.

---Dan