Re: [TLS] New drafts: adding input to the TLS master secret

Martin Rex <mrex@sap.com> Tue, 02 February 2010 21:54 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 026AD3A6933 for <tls@core3.amsl.com>; Tue, 2 Feb 2010 13:54:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.222
X-Spam-Level:
X-Spam-Status: No, score=-10.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UMqhid7NrLW for <tls@core3.amsl.com>; Tue, 2 Feb 2010 13:54:33 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id DA89E3A67E9 for <tls@ietf.org>; Tue, 2 Feb 2010 13:54:32 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o12Lt73j011342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2010 22:55:08 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201002022155.o12Lt6sO028731@fs4113.wdf.sap.corp>
To: brian@briansmith.org (Brian Smith)
Date: Tue, 2 Feb 2010 22:55:06 +0100 (MET)
In-Reply-To: <001101caa44b$35f6f540$a1e4dfc0$@org> from "Brian Smith" at Feb 2, 10 03:03:41 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: paul.hoffman@vpnc.org, tls@ietf.org
Subject: Re: [TLS] New drafts: adding input to the TLS master secret
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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/listinfo/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, 02 Feb 2010 21:54:34 -0000

Brian Smith wrote:
> 
> Any  extensions that contain non-trivial amounts of data and/or possibly
> sensitive information should be transmitted after change_cipher_spec
> messages--not in hello messages--whenever practical. When a hello extension
> does contain non-trivial amounts of information or sensitive information,
> then the security considerations section of its specification should explain
> why the extension cannot be moved to after the change_cipher_spec messages. 

As far as I understand, the proposals are about adding entropy into
the TLS MasterSecret computation, not about adding sensitive information.

When using an extension, that additional entropy could also be used
for deriving new keying material (connection parameters) on
TLS session resumption (because these handshake messages do exist
in the abbreviated handshake), but since the existing proposal are
specific about MasterSecret computation, that seems not to be an
issue here (session resumption does _not_ change the session's
MasterSecret).

Currently, the entropy depends on the ClientHello.Random
and ServerHello.Random (28 bytes for use available for each peer),
plus the result of the keyExchange algorithm (with plain RSA ciphersuites,
the client gets to chose/generate all that data/randomness)

In the existing TLS architecture, it is not allowed to send
any message between ChangeCipherSpec and Finished, and Finished
is also the very first message protected under the connection
parameters for the newly created TLS session based on the
sessions MasterSecret.

Before the transmission of the ClientKeyExchange handshake message,
there are no common cryptographic parameters that could be used
for protection at all.

If you wanted to get some sensitive data transfered within the
initial TLS handshake, it would have to be done after ClientKeyExchange
(and if we ever come up with a scheme to protect the client identity
in TLS already in the initial handshake, the (client's) Certificate
and ClientKeyExchange handshake message would have to change their
places in order from where they are currently sent.


What puzzles me a little is that why the existing 28 bytes of
Random in both Hello handshake messages should not be sufficient
for the purpose.  Is there problem in "compressing" large amount
of low-entropy data into that 28-byte of randomness (lack of
suitable compression function)?


Technically, I could conceive that a TLS implementation offers to
application callers a possibility to supply extra entropy that the
TLS implementation will "consume" when producing the 28 bytes
of Hello.Random.  That could be done immediately at the discretion
of every TLS implementation and not require any protocol changes
at all.


-Martin