Re: [Cfrg] Side inputs to signature systems, take 2

[Daniel Kahn Gillmor <[e-mail]>]

Hi Dan--

On Sat 2016-04-23 08:59:54 -0400, D. J. Bernstein wrote:
>    * The security analysis is almost entirely missing. It's easy to come
>      up with examples where the idea seems to work, but slightly more
>      thought shows many more examples where the idea fails, because it's
>      not directly aimed at the core cross-protocol issue.

This seems to be saying that because domain separation by context labels
doesn't solve all conceivable cross-protocol issues (i agree it does
not) that we should not use it to address those issues that it does
solve.

Your PGP example is definitely correct.  The PGP signature would not
prevent collisions of multiple PGP messages with different
interpretations.  However, it *would* prevent a PGP signature from being
replayed as a signature on a TLS certificate verify message from the
same secret key (or a PKINIT message in krb5, etc)

>    * The syntax/layering/API analysis is entirely missing. In every case
>      where the idea is effective, the same benefit is also achieved by a
>      much more traditional fix that _doesn't_ change the signature API,
>      and this traditional fix is much easier from a systems perspective.

i'm assuming that the "traditional fix" is just "incorporate a sane
context-specific bytestring into the message being signed".  And I
agree, it would be great if people did that.  But calling it a
"traditional fix" implies that there is a tradition of doing the right
thing here, and that's been inconsistent at best.

Do you have a better suggestion of how to formalize this practice than
giving protocol designers a place to put a distinct context?  I'd be
happy with other proposals that try to address the same issue.

Thanks for the thoughtful discussion,

     --dkg