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

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

Return-Path: <alangley@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 31A941A0015 for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 22:55:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.678
X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ojI0g4TH_8NP for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 22:55:31 -0800 (PST)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33F1C1A0008 for <tls@ietf.org>; Mon, 24 Nov 2014 22:55:31 -0800 (PST)
Received: by mail-la0-f46.google.com with SMTP id gd6so8877379lab.5 for <tls@ietf.org>; Mon, 24 Nov 2014 22:55:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=D7PeUb3EWfixGpwGPV30/pVUOD63i2y7PpFucDP8rCA=; b=Zx+fVgQSiU8pnpi5m8Vs4+I7dJKRV4uv5r2hfPkz0dOWB37u+amhxbW+6+bZ3xjmGR GFznNAb/BCR4Pci+pJ3RLbGroP7nfQ8KhJvoRvF1OLV3hqRpVwTqltEb/WaFjptmj8Zl P7UcE5SP5B/PiAwxaTfwHb6917n17TfOexbpztjsCBZwrMBrf8XAw4iKnmIJoAVNRBuy tZXMCrepOF8Or7Gl7+tXGLOYhGibWhN4sprS+Crr3Di0RPGyxxPUBAs3Fb6wBdneT+Lq UWRKCZrrWBULeIwpbLQQd+/m3ubOkTbdm/rhl3997Qz4Pa4Ox5BwZV2+1j/adAF/+Tpv rTMg==
MIME-Version: 1.0
X-Received: by with SMTP id ug7mr24394223lbb.73.1416898529645; Mon, 24 Nov 2014 22:55:29 -0800 (PST)
Sender: alangley@gmail.com
Received: by with HTTP; Mon, 24 Nov 2014 22:55:29 -0800 (PST)
Date: Mon, 24 Nov 2014 22:55:29 -0800
X-Google-Sender-Auth: kyfRb_Yt1XS72l1sWyZeZac75No
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.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 06:55:33 -0000

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-
[4] https://tools.ietf.org/html/rfc5246#section-7.4.3



Adam Langley agl@imperialviolet.org https://www.imperialviolet.org