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

[David Jacobson <[e-mail]>]

On 4/23/16 1:19 PM, Daniel Kahn Gillmor wrote:
> 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.

A second traditional fix is "never use the same key for two different 
purposes".  And if the "general" in DBJ's story can't deal with many 
keys, then use a KDF to derive a key for each purpose from the general's 
key.  You can even have multi-level use of KDFs.  Once can be each 
semantic domain the general uses, and a second level can be for 
protocols (e.g. "PGP"), etc., as deep as you need to go.

This keeps the issue of domain separation independent of encryption APIs 
and algorithms.

     --David Jacobson

>
> 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
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg