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

Nikos Mavrogiannopoulos <> Tue, 02 December 2014 08:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C0AB81A01FA for <>; Tue, 2 Dec 2014 00:29:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pYJ7i3HVhaD8 for <>; Tue, 2 Dec 2014 00:29:36 -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 2C8B81A01F6 for <>; Tue, 2 Dec 2014 00:29:35 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id sB28TX5d006215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 2 Dec 2014 03:29:33 -0500
Received: from [] ( []) by (8.14.4/8.14.4) with ESMTP id sB28TUMt001031 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2014 03:29:31 -0500
Message-ID: <>
From: Nikos Mavrogiannopoulos <>
To: Adam Langley <>
Date: Tue, 02 Dec 2014 09:29:29 +0100
In-Reply-To: <>
References: <> <> <> <> <>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on
Cc: "" <>
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, 02 Dec 2014 08:29:37 -0000

On Mon, 2014-12-01 at 14:28 -0800, Adam Langley wrote:
> On Wed, Nov 26, 2014 at 6:09 AM, Eric Rescorla <> wrote:
> > If someone wants to contribute a PR so that we can have something
> > concrete to look at that would be even better.
> I have submitted a PR for the padding and context-string changes:
> I did not change the CertificateVerify structure in the same commit
> because I'm not quite sure that I follow the reasoning. The
> CertificateVerify implicitly contains the client and server nonce
> because it contains all the preceding handshake messages. What's the
> motivation for duplicating them at the beginning? Is it simply to
> avoid having the opaque signer understand the TLS structure? If so,
> does the padding and context strings that I've just proposed break
> that?

Is this about the comment in ?
If yes, it is unrelated to the context issue. By having an explicit
server random value, a server can delegate the TLS protocol to a worker
process, while he can still verify that the connected peer is the
intended. For that, the server only needs to explicitly set the
server_random data and then verify the client's CertificateVerify
message based on that. That would allow  designs with privilege
separation (e.g., similar to openssh's) to use TLS. Without the explicit
random values, the server would have to receive the whole TLS transcript
and calculate the hash over it.

In short it allows the server or the client to provide a short proof
that they established a session with a particular peer.