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

Nikos Mavrogiannopoulos <> Thu, 22 April 2010 16:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A87C3A685E; Thu, 22 Apr 2010 09:01:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RNPtbedp4QBf; Thu, 22 Apr 2010 09:01:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 59C0428C12A; Thu, 22 Apr 2010 09:01:20 -0700 (PDT)
Received: by wwb24 with SMTP id 24so1411319wwb.31 for <multiple recipients>; Thu, 22 Apr 2010 09:01:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Pz9CZB/Iy0X3FetFKZllkvmhEaaH7LdodccBfiIonkM=; b=bVAj+LyyuJmS2Jdgf4NOYxDJEIPkFwQ/TBmaSKeL83Ud3pAyw+AUNoPGxOOikp6ydw lwc85QOXWMorb7rO3fnMqvTbtA7Qec79WetTd4F3ec6x2ErkKXq956WwNgastLY31p7p dgM31N6+2frixr8yQXuYj+qSzJG2F1oNKIaME=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=MCVYX9d5j0YKJ2N1pXkwfyyCD/gCWMXxPEedpHDhaYhP5EobbB+wnFLgrEHK9hHY+W IIOGRQwriEvsLiWwgBHXjgcTbbwdJfBabCTDbwnMoZeYF2H0pMM2rXMglE9awyXxwq9D KdXkO9IO4EIaPqifw8t/6Blwf626ZGJN5A3Ao=
MIME-Version: 1.0
Received: by with HTTP; Thu, 22 Apr 2010 09:01:05 -0700 (PDT)
In-Reply-To: <p06240803c7f60d8cde2c@>
References: <> <p06240887c7f52b14f905@> <> <p06240803c7f60d8cde2c@>
Date: Thu, 22 Apr 2010 18:01:05 +0200
X-Google-Sender-Auth: 52329d786071fcf8
Received: by with SMTP id 19mr2360042mup.111.1271952065979; Thu, 22 Apr 2010 09:01:05 -0700 (PDT)
Message-ID: <>
From: Nikos Mavrogiannopoulos <>
To: Paul Hoffman <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Simon Josefsson <>,,
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: Thu, 22 Apr 2010 16:01:41 -0000

On Thu, Apr 22, 2010 at 4:29 PM, Paul Hoffman <> wrote:

>>In which environments is the extension useful?
>>The only motivation in the document that I can find is this:
>>  In some application environments, it is desirable to have the client
>>  and/or the server be able to input more random material in the master
>>  key calculation than is allowed by the fixed-length Random value.
>>I believe more justification than that is required for Proposed
>>In particular, what I'd like to see is references to some application
>>environments where the extension is desirable, and the rationale why it
>>is desirable in that environment.
>>Without a rationale for when the extension is useful, it is impossible
>>for implementers to know when use of this extension is warranted or not.
> The environment I described in the earlier thread is TLS with
> Diffie-Hellman. I thought that saying that was sufficient, but I guess
> it wasn't.
> In Diffie-Hellman key establishment with static keys, even if the PRNG
> of one side is bad, the resulting pre-master secret is still sound.
> Neither side knows whether or not the PRNG of the other side is bad, so
> each side wants to supply sufficient randomness for the master secret
> even if the other side's PRNG is bad. If a side with a bad PRNG adds its
> own input, it doesn't hurt the randomness of the result, but a side with
> a good PRNG can bring up the amount of randomness.
> I did not want to list this as the justification because there may be
> other reasons to use the extension, and I don't want readers to think
> that this is the only one. For example, future types of TLS key
> establishment might have similar properties as static-static
> Diffie-Hellman.

Maybe or maybe not. I'd prefer extensions to TLS that solve existing
issues or  augment with new functionality. If there really an issue
with TLS with static DH keys that is solved by this draft I can
understand specifying it, or better I'd prefer solving them within the
protocol and without any extensions to it. But if there no practical
issue I see no point. In the end who's really getting affected by this