IETF Logo Mail Archive

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

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 03 February 2010 03:13 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 BCE553A69C9 for <tls@core3.amsl.com>; Tue, 2 Feb 2010 19:13:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.05
X-Spam-Level:
X-Spam-Status: No, score=-6.05 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 gDzBRQifMKZr for <tls@core3.amsl.com>; Tue, 2 Feb 2010 19:13:39 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id C34B328C0E0 for <tls@ietf.org>; Tue, 2 Feb 2010 19:13:37 -0800 (PST)
Received: from [75.101.18.87] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o133EEcB094856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2010 20:14:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p0624083cc78e981d35bf@[75.101.18.87]>
In-Reply-To: <201002030218.o132I6Y2014454@fs4113.wdf.sap.corp>
References: <201002030218.o132I6Y2014454@fs4113.wdf.sap.corp>
Date: Tue, 02 Feb 2010 19:14:13 -0800
To: mrex@sap.com, marsh@extendedsubset.com
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
Cc: 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
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: Wed, 03 Feb 2010 03:13:54 -0000

At 3:18 AM +0100 2/3/10, Martin Rex wrote:
>Marsh Ray wrote:
>>
>> Paul Hoffman wrote:
>> >
>> > This proposed protocol change is only relevant to scenarios where
>> > there is a cryptographic reason to mix inherently non-sensitive data
>> > passed before the change_cipher_spec message into the master secret.
>>
>> You said the data is "not sensitive" and it is sent in plain text. So an
>> attacker has it as soon as the endpoints do.
>>
>> What does this accomplish over just hashing your extra data into the 28
>> byte random field? (which would not require a new protocol structure)
>
>I had the same thought.  Have the endpoints hash it into the
>random fields that are sent in the ClientHellos.

This makes no sense from a cryptographic standpoint. The ClientHello has a fixed size of 28 bytes, so you have 28 bytes of randomness. Combining that with more random data, hashing, and truncating to 28 bytes leaves you with exactly 28 bytes of randomness: you don't gain anything. This isn't a protocol issue, it's a cryptographic fact.

>Adding extra data onto every TLS handshake that will _only_ be
>used during full handshake and completely useless for all session
>resumptions seems like a waste.

This is incorrect. Session resumption uses the original master key. Therefore, whatever data was mixed in to the original master key is mixed into all future keys as well. Or are you saying that the security analysis in F.1.4 of RFC 5246 is wrong in some way?

> > How big were you planning to make those symmetric keys anyway?
>
>I would prefer to _not_ call anything "key" that is going to
>travel in the clear.  Personally, I always think of "keys" being
>secret or even private information.   I would prefer the term
>"random" or "entropy".

Ah, I didn't see that Marsh meant "random input" when he said "key" there. Martin is correct about the terminology. These are *not* keys, and nothing in the draft suggests that they are.

--Paul Hoffman, Director
--VPN Consortium

v2.23.0 | Report a Bug | By Email