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

Adam Langley <agl@imperialviolet.org> Tue, 25 November 2014 06:55 UTC

MIME-Version: 1.0
Sender: alangley@gmail.com
Date: Mon, 24 Nov 2014 22:55:29 -0800
Message-ID: <CAMfhd9XgR-N6BZVLojfyf6E2+0fhYVHopp5FKALoup_GjTji5A@mail.gmail.com>
From: Adam Langley <agl@imperialviolet.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kNHaCbvPbc7WQbdaqH3r5Kd4UpE
Subject: [TLS] Signed messages should be prefixed with a NUL-terminated context string.
Precedence: list

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] Signed messages should be prefixed with a N… Adam Langley
Re: [TLS] Signed messages should be prefixed with… Nikos Mavrogiannopoulos
Re: [TLS] Signed messages should be prefixed with… Eric Rescorla
Re: [TLS] Signed messages should be prefixed with… Nikos Mavrogiannopoulos
Re: [TLS] Signed messages should be prefixed with… Eric Rescorla
Re: [TLS] Signed messages should be prefixed with… Adam Langley
Re: [TLS] Signed messages should be prefixed with… Nikos Mavrogiannopoulos
Re: [TLS] Signed messages should be prefixed with… Eric Rescorla
Re: [TLS] Signed messages should be prefixed with… Ilari Liusvaara
Re: [TLS] Signed messages should be prefixed with… Eric Rescorla
Re: [TLS] Signed messages should be prefixed with… Ilari Liusvaara
Re: [TLS] Signed messages should be prefixed with… Eric Rescorla
Re: [TLS] Signed messages should be prefixed with… Ilari Liusvaara
Re: [TLS] Signed messages should be prefixed with… Eric Rescorla
Re: [TLS] Signed messages should be prefixed with… Adam Langley
Re: [TLS] Signed messages should be prefixed with… Michael StJohns
Re: [TLS] Signed messages should be prefixed with… Watson Ladd
Re: [TLS] Signed messages should be prefixed with… Adam Langley
Re: [TLS] Signed messages should be prefixed with… Eric Rescorla
Re: [TLS] Signed messages should be prefixed with… Michael StJohns
Re: [TLS] Signed messages should be prefixed with… Eric Rescorla
Re: [TLS] Signed messages should be prefixed with… Michael StJohns
Re: [TLS] Signed messages should be prefixed with… Eric Rescorla
Re: [TLS] Signed messages should be prefixed with… Eric Rescorla