Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random

Marsh Ray <> Mon, 26 April 2010 22:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4EDE43A6BD4; Mon, 26 Apr 2010 15:10:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.374
X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uHnBeVm6Vx+O; Mon, 26 Apr 2010 15:10:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 097F83A6BBA; Mon, 26 Apr 2010 15:10:51 -0700 (PDT)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1O6WVi-0005e8-KU; Mon, 26 Apr 2010 22:10:38 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id D73AF60B6; Mon, 26 Apr 2010 22:10:36 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX19Ka10OEta22YnbA1GsJRfAnCll2EJLfv0=
Message-ID: <>
Date: Mon, 26 Apr 2010 17:10:35 -0500
From: Marsh Ray <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: Nicolas Williams <>
References: <> <> <> <> <20100426213634.GD10389@Sun.COM>
In-Reply-To: <20100426213634.GD10389@Sun.COM>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc:, Paul Hoffman <>,
Subject: Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Apr 2010 22:10:52 -0000

On 4/26/2010 4:36 PM, Nicolas Williams wrote:
> On Mon, Apr 26, 2010 at 04:18:33PM -0500, Marsh Ray wrote:
>> Taking off of CC list as this seems to be very TLS specific.
> This is an IETF LC, not a WG LC; IETF LC comments should be sent to
>  If anything, we might want to drop

That makes sense.

> Thus ISTM that we should first consider either whether the client_random
> and server_random fields are sufficient _assuming_ compliant [P]RNGs or
> consider how draft-hoffman-tls-additional-random-ext can ameliorate TLS
> implementations that have poor [P]RNGs.

I think the current space in the protocol of 224-256 bits in each
direction is sufficient. Well-known techniques exist for compressing
whatever format of entropy is available into that space.

> Ah!  Perhaps what's happening here is that Paul intends for the
> additional random inputs to be provided by the _application_, from
> outside the TLS implementation.  In that case an application could make
> secure use of TLS even when the underlying TLS implementation has a poor
> [P]RNG.  That would make draft-hoffman-tls-additional-random-ext much
> more interesting (combined with some editing I'd drop my objections).

But that facility could be provided by the implementation API without
any need to extend the TLS protocol. Indeed, OpenSSL provides a function
to contribute entropy into its RNG.

Thus I do not think draft-hoffman-tls-additional-random-ext should be
advanced as a standard.

- Marsh