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

Nikos Mavrogiannopoulos <> Tue, 25 November 2014 12:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 71F671A016A for <>; Tue, 25 Nov 2014 04:40:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5ck7Q_WfE9za for <>; Tue, 25 Nov 2014 04:40:01 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7EC1D1A0166 for <>; Tue, 25 Nov 2014 04:40:01 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id sAPCdxEA013794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 25 Nov 2014 07:40:00 -0500
Received: from [] ( []) by (8.14.4/8.14.4) with ESMTP id sAPCdv45004536 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2014 07:39:58 -0500
Message-ID: <>
From: Nikos Mavrogiannopoulos <>
To: Adam Langley <>
Date: Tue, 25 Nov 2014 13:39:57 +0100
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on
Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string.
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Nov 2014 12:40:03 -0000

----- 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.