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

Paul Hoffman <> Fri, 23 April 2010 14:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9282228C0E1; Fri, 23 Apr 2010 07:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.421
X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[AWL=-1.975, BAYES_50=0.001, HELO_MISMATCH_COM=0.553]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F5iqEVSGigQ3; Fri, 23 Apr 2010 07:15:16 -0700 (PDT)
Received: from (Hoffman.Proper.COM []) by (Postfix) with ESMTP id EA36D28C0DE; Fri, 23 Apr 2010 07:14:48 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.3) with ESMTP id o3NEEaOl007926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Apr 2010 07:14:38 -0700 (MST) (envelope-from
Mime-Version: 1.0
Message-Id: <p06240801c7f75b4444b0@[]>
In-Reply-To: <>
References: <> <p06240887c7f52b14f905@[]> <>
Date: Fri, 23 Apr 2010 07:13:14 -0700
From: Paul Hoffman <>
Content-Type: text/plain; charset="us-ascii"
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: Fri, 23 Apr 2010 14:15:17 -0000

Hi again. It appears that people have a hard time with the additional random extension because it has limited applicability but I cannot fully state what that is. The purpose here is to help fix problems that shouldn't happen, and to be harmless when the bad situation doesn't happen. This has led some people to think that an implementer will therefore feel free to code more carelessly. I have a higher respect for TLS implementers, but maybe I shouldn't.

I am not sure that I can convince people of what seems like an obvious fact: the PRNG on a system might fail in a way that the TLS implementation cannot detect. If it could detect the failure, of course it should shut down, screaming. But lots of PNRG failures seem undetectable to the implementation but possibly detectable to an attacker. Remedying that was the motivation for these drafts. If that problem is not of interest, or is considered to induce developers to do a worse job, I can see why people would not want these drafts to move forwards.

I still believe that this extension itself is harmless in all cases, and helpful in limited ones; I have not seen anyone directly prove otherwise. Having said that, I'm of course willing to go along with IETF consensus if people think that the mere standardization of this extension will somehow weaken existing implementations.

--Paul Hoffman, Director
--VPN Consortium