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

"Brian Smith" <brian@briansmith.org> Tue, 02 February 2010 20:02 UTC

Return-Path: <brian@briansmith.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 47A673A6A46 for <tls@core3.amsl.com>; Tue, 2 Feb 2010 12:02:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Level:
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_00=-2.599, SARE_RAND_1=2]
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 SAUm55TqBMqQ for <tls@core3.amsl.com>; Tue, 2 Feb 2010 12:02:33 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 685713A6A3C for <tls@ietf.org>; Tue, 2 Feb 2010 12:02:33 -0800 (PST)
Received: from T60 (unknown [70.245.64.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D21D8509DF; Tue, 2 Feb 2010 15:03:05 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'Paul Hoffman'" <paul.hoffman@vpnc.org>
References: <p0624089bc78922bdaddd@[10.20.30.158]> <87fx5jk8vp.fsf@mocca.josefsson.org> <p06240813c78e116da3f6@[75.101.18.87]>
In-Reply-To: <p06240813c78e116da3f6@[75.101.18.87]>
Date: Tue, 2 Feb 2010 14:03:05 -0600
Message-ID: <001001caa442$beefbde0$3ccf39a0$@org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Content-Language: en-us
Thread-Index: AcqkLoWT7xt7+EDrRx67KJiJLEnvUwAELCkw
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: Tue, 02 Feb 2010 20:02:34 -0000

Paul Hoffman wrote:
> At 3:30 PM +0100 2/2/10, Simon Josefsson wrote:
> >There is one thing in draft-hoffman-tls-additional-random-ext-00.txt
> >that bothers me: There is no requirement that additional random data
> >is generated using cryptographic principles.  This means the extension
> >can be used as a general-purpose extension mechanism to exchange data
> >that has meaning to, for example, some middle-ware that sits between
> >the client and server.
> >
> >Is this the intention?  I'm assuming no, and that the
> >additional_random_value actually are intended to be, well, just an
> >additional random value.
> 
> Correct. That's why the document says:
>    The recipient of an additional_random extension MUST NOT try to
>    parse the additional_random_value.
> 
> >Therefor, I would suggest that a new requirement is added:
> >
> >   The client and server MUST generate the additional_random_value
> >   data using a secure random number generator.  [RANDOM] provides
> >   guidance on the generation of random values.
> 
> This is a great addition, thanks. It will be in the -01.

 (a) Why does the intro say that extensions want to mix "particular data"
into the calculation of the master secret? I think "additional random data"
would be clearer.

(b) Why does there need to be more than one kind of additional input type?
It seems like the sending side could just concatenate all the additional
input into a single "additional_input" extension before it sends it. I think
it's because this foundational work for channel binding mechanism. In that
case, the IETF should treat the this mechanism and the channel binding
mechanism as a single item to be accepted/rejected together--if channel
binding gets rejected then there's no need (AFAICT) for multiple
additional_input extensions.

(c) Besides channel binding, an implementation might support this to help
ensure a certain level of entropy was used for the pseudorandom inputs to
the PRF for calculating the master secret. Why not include the definition of
this extension in the same document, instead of requiring a separate
document to define it?

(d) Wouldn't it be better to use the normal master_secret calculations to
establish a secure channel, and then send the parameters for modifying the
master secret over that secure connection? This would reduce the amount of
data sent in the clear, so that an outside observer could not tell if/which
channels are bound together. And it would reduce DoS on the entropy source
of the PRNGs of each party, by allowing each party to authenticate the other
before processing the extension. Finally, it would keep ClientHello messages
small, which is important for improving latency.

Regards,
Brian