Re: [Cfrg] Help with the use of contexts

[Ilari Liusvaara <[e-mail]>]

On Sun, Feb 05, 2017 at 08:48:01AM +0100, Tibor Jager wrote:
> On 03/02/2017 13:55, Ilari Liusvaara wrote:
> > On Fri, Feb 03, 2017 at 09:16:11AM +0100, Tibor Jager wrote:
> >> On 30 January 2017 at 12:40, Paterson, Kenny <[e-mail]>
> >> wrote:
> >>
> >>> So: does anyone else want to offer an opinion on the question of
> contexts?
> >>>
> >>>
> >> Contexts are a clean and relatively simple way to prevent cross-protocol
> >> attacks, in particular when implemented in an as simple way as proposed
> >> by Adam and Dan.
> >
> > Unfortunately, in practice those are anything but clean and simple.
> >
> > Yes, the theoretical notion is pretty simple (where (context,message)
> > tuple replaces the message in standard notion of signature security).
> >
> > The biggest practical problem: Backwards compatiblity, the ever-present
> > nemsis of security.
> 
> We do not have to change old protocols in order to enable domain separation
> via contexts in new protocols:
> 
> - Old protocols: keep signing messages as before: sig = Sign(sk, m)
> - New protocols: sign messages as sig = Sign(sk, ctx||m)

The problem is, that keys need to be separated as well.

If it is just a protocol that stands alone, then one may just declare
its keys to be suitable.

However, if it uses external keys, you are faced with separating these
keys, which means changes to the key format. And if external keys are
critically used in some other way, you need to modify this use as well.

Implication of above for TLS:

- TLS critically relies in practice on X.509 SPKI key format and X.509
  CSRs.
- Reliance on SPKI impiles that new SPKI key type would be needed.
- Reliance on CSR would mean new X.509 signature type would be required.

Yes, the new key type and new signature type are not difficult to
define, but still need to be done for the scheme to give security.

> Here, ctx is a "unique" and sufficiently large context string, which even
> in presence of an attacker is unlikely to occur in the message m of any
> existing protocol. For example, one could use the ASCII string "TLS 1.3 TLS
> 1.3 TLS 1.3 ...", repeating "TLS 1.3" a suitable number of times. The
> symbol || denotes concatenation of bytes, possibly with a NULL-byte as a
> separator.

Fails the basic notion of security of contextualized signatures.

> This is how I understand the solution pointed to by Adam and explained by
> Dan, and it seems similar in spirit to (but simpler than) what Natanael
> described. In particular, it seems not to break backwards compatibility
> with existing protocols, but would allow a smooth transition to the use of
> contexts to achieve domain separation, and thus help to prevent
> cross-protocol attacks.

I don't think they described the catch with this type of construction...


-Ilari