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

This seems like a good idea. Thanks for raising it.

If you want to make a PR, I will merge it in.

-Ekr

On Mon, Nov 24, 2014 at 10:55 PM, Adam Langley <agl@imperialviolet.org>
wrote:

> 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:
>
> Mavrogiannopoulos, Vercauteren, Velichkov and Preneel[1] showed a
> near-miss in the design of TLS <= 1.2 due to a lack of context in
> ServerKeyExchange messages resulting in an ambiguity about whether a
> specific message was DHE or ECDHE.
>
> 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:
>
> An attacker watches for the ClientHello from the client. Assume, as is
> quite common now, that the client generates its client_random with 32
> random bytes (i.e. there's no timestamp). With probability 2^-32, the
> client_random will start with 0x0100 and bytes 4 and 5 will be 0x03
> and 0x04.
>
> The attacker now connects to the TLS 1.3 server and sends a
> ClientHello such that the prefix of the message (including handshake
> message type and length) is equal to the victim client's client_random
> value. (Most of the bytes can be put into the attacker's client_random
> value and the restriction on the victim client's message ensures that
> the handshake type, length and protocol version are taken care of.)
>
> With the rest of the ClientHello, the attacker is free to make the TLS
> 1.3 handshake look like a TLS 1.2 ServerKeyExchange message. An
> obvious choice is to stuff a dummy server_random into the session ID
> and specify a small p and g such that a discrete-log is easy, then
> consume the rest of the handshake with a huge Y. (The length of the
> TLS 1.3 handshake from the server is predictable.)
>
> Some clients might check that Y < p but, if they do the obvious thing,
> then the TLS 1.3 server's signature over the handshake can be used as
> a TLS 1.2 ServerKeyExchange signature and the client compromised.
>
>
> I may have missed something and, even if not, the restrictions on the
> client's client_random value make it an expensive attack to pull off.
> But it's still another near-miss.
>
> Thus I suggest that signed messages in TLS 1.3 be prefixed with
> context strings. For example, "TLS 1.3 CertificateVerify message from
> server\x00" in this case.
>
> However, since TLS <= 1.2 provides an attacker the ability to get a
> signature for a message with a 32-byte, chosen prefix via the
> ServerKeyExchange, I additionally suggest that the context string
> start with 48-64 bytes of "PADTLS" repeated, in order to clear that
> prefix and cover part or all of the server_random.
>
> (And that signature oracle in TLS <= 1.2 provides another reason,
> should any be needed, not to run a CA:TRUE certificate on a server.)
>
>
> [1] https://www.cosic.esat.kuleuven.be/publications/article-2216.pdf
> [2] https://tlswg.github.io/tls13-spec/#rfc.section.7.4.7
> [3] https://tools.ietf.org/html/rfc5246#section-7.4.1.2
> [4] https://tools.ietf.org/html/rfc5246#section-7.4.3
>
>
> Cheers
>
> AGL
>
> --
> Adam Langley agl@imperialviolet.org https://www.imperialviolet.org
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>