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

[Benjamin Kaduk <[e-mail]>]

On Wed, 20 Apr 2016, Daniel Kahn Gillmor wrote:

> On Wed 2016-04-20 16:51:20 -0400, D. J. Bernstein wrote:
>
> >       * More to the point, how is this supposed to be better than having
> >         the application sign a more informative message, using the
> >         traditional concept of a signature system?
>
> "more informative" assumes that you know exactly how any bytestring is
> going to be interpreted in every other context.

To perhaps step back a bit, a signature scheme taking an optional context
label input with specified semantics (i.e., the label is prepended,
recommended to end with a NUL byte, etc.) is a way to strongly suggest
that application protocols using that signature scheme provide such "more
informative message"s, and gives guidance as to what the structure of the
more informative message could be.

I don't really care if the application protocol makes its message being
signed more informative (i.e., specific to the particular protocol message
at hand) by manually putting that data at the front of its signing input
and ignoring the context input, or by using the context input.  I just
want it to happen, since that improves the overall safety of the internet.

> If we define a standard way that a signature or key derivation domain
> can distinguish itself from any other domain, then we can avoid
> cross-protocol attacks for every scheme that adopts this standard.
>
> Without it, each protocol will define how it thinks it should structure
> a message that is "informative enough" to be distinct from every other
> signed message in every other protocol -- but how will this be
> determined without cross-protocol coordination?  This mechanism offers a
> means for cross-protocol coordination by selection of distinct context
> strings.  (for signature schemes like Ed448 that aren't using the
> prefix-approach, the only requirement is context string uniqueness,
> since they are prefix-resistant)

Having a contetx input to newly specified signature schemes (and a
registry to ensure global prefix-uniqueness, which dkg and Martin and I
are working on a draft for) is a way to help protocol designers that
aren't cryptographers do the right thing, cryptographically speaking.
Perhaps there are better ways to encourage this behavior, but this is the
best proposal I've seen so far, for this issue.

-Ben