Should the signing payload include 64 spaces in front?

[davidben]

Feedback from Ilari Liusvaara on the list:

• I think LabeledWindow should add 64 spaces in front, so it reuses the TLS 1.3 signature format.

  This reduces risks of cross-protocol attack if the key gets reused anyway (despite there being MUST NOT requirement).

I'm slightly torn on this, though I don't feel very strongly either way. (Past Davids have gone both directions on this.)

On one hand, it costs very little and reduces cross-protocol attacks with TLS 1.2 if you reuse keys. Even though we explicitly told you not to reuse those keys.

On the other hand, it only reduces attacks with TLS 1.2, and this key was already explicitly not meant to be a TLS key. Where do such things end? Should every new protocol forever guard against potential reuse with TLS 1.2, even when it (like this one) was not designed to be used with TLS? Should we guard against reuse with other protocols too? Context string constructions aren't standard (hash-to-curve does a suffix instead of a prefix), so the real defense is key separation. Maybe we should finally just get better at key separation.

[bwesterb]

I think it's good practice to add some context, which we already do, so that we can use the Merkle CA's key to sign other things besides the window. This also helps against accidental cross-protocol attacks. (Unfortunately we all haven't agreed on the standard way to do this. It'd be nice if every signature scheme would have a context string as input, but that's a separate discussion.)

I don't think it's worthwhile to add the 64 spaces in front, if we mandate separate keys. We wouldn't just have to deal with TLS, but every other protocol where the same key can be used as well.