Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string.

[Nikos Mavrogiannopoulos <[e-mail]>]

----- Original Message -----
> I generally recommend that, whenever signing a message, a
> NUL-terminated, ASCII context string is prepended to the message to
> ensure that the verifier isn't confused about the context.
> (NUL-terminated, ASCII strings have the property that none is a prefix
> of any other.)
> 
> I think that TLS 1.3 provides a good demonstration of why:
[...]
> TLS 1.3 has the server return a CertificateVerify message[2] that
> signs the handshake so far, similar to TLS <= 1.2's message of the
> same name. However, consider a client that implements any version of
> TLS and a server that implements TLS 1.3:

Thanks for bringing that up, as it is an interesting issue. I read the changes
to TLS 1.3, and the current approach in TLS 1.3. as I understand is to use the 
following construction for both client and server certificate verify.
      struct {
           digitally-signed struct {
               opaque handshake_messages[handshake_messages_length];
           }
      } CertificateVerify;

That would mean that CertificateVerify is compatible between a server and client,
and I believe this was the thing the designers of SSL 3.0 wanted to avoid when
they made different signature formats for each message.

To add to your attack for that construction, an attack in early crypto
protocols was a client using the server signed response to authenticate using the 
server's own key (Unfortunately I don't remember where this was first described).
While in TLS 1.3 the hash contents will be different at the point both messages 
are sent, and the attack doesn't directly apply, I think the fact that the format 
of two different signatures matches cleanly is a reason for concern.

I am for using any kind of distinguisher to make these messages context dependent.

regards,
Nikos