Re: [TLS] New draft: draft-solinas-tls-additional-prf-input-00.txt

Paul Hoffman <> Wed, 07 October 2009 00:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D6C428C1D2 for <>; Tue, 6 Oct 2009 17:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.21
X-Spam-Status: No, score=-5.21 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dH9BD4GmpKBe for <>; Tue, 6 Oct 2009 17:15:15 -0700 (PDT)
Received: from (Balder-227.Proper.COM []) by (Postfix) with ESMTP id 8B57B28C0E1 for <>; Tue, 6 Oct 2009 17:15:15 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.2/8.14.2) with ESMTP id n970GnA3048329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Oct 2009 17:16:50 -0700 (MST) (envelope-from
Mime-Version: 1.0
Message-Id: <p06240826c6f18d5f99ae@[]>
In-Reply-To: <>
References: <>
Date: Tue, 06 Oct 2009 17:16:38 -0700
To: Michael Gray <>
From: Paul Hoffman <>
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [TLS] New draft: draft-solinas-tls-additional-prf-input-00.txt
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: Wed, 07 Oct 2009 00:15:16 -0000

At 9:35 AM +1000 10/7/09, Michael Gray wrote:
>Comparing this with draft-rescorla-tls-extended-random-02.txt I see the
>requirement for the size of Server response is missing and thus undefined.

Correct. Both sides send arbitrary-length values.

>From 3.1 in the above we have:
>   If the server wishes to use the extended randomness feature, it MUST
>   send its own "extended_random" extension with an
>   extended_random_value equal in length to the client's
>   extended_random_value
>Additionally, I think some limitation of the size/amount of data that can
>be requested from a server is needed as large sizes could pose an attack on
>a server by exhausting the entropy pool and/or causing server performance

In this proposal, server never "requests" any particular size. The client offers its value in the extended_random extension, and the server offers its value in the reply.

>  Our prototype implementation allows servers to ignore or
>respond with error, depending on configuration, requests from clients that
>are larger than 256 octets.

...which is a good reason why we abandoned the "request a size" semantics.

--Paul Hoffman, Director
--VPN Consortium