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

Simon Josefsson <simon@josefsson.org> Fri, 23 April 2010 15:29 UTC

Return-Path: <simon@josefsson.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 7E65B3A6A26; Fri, 23 Apr 2010 08:29:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 LV2OwKacekq1; Fri, 23 Apr 2010 08:29:04 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 492153A6A1D; Fri, 23 Apr 2010 08:29:03 -0700 (PDT)
Received: from mocca (c80-216-24-99.bredband.comhem.se [80.216.24.99]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3NFSmFi002570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 23 Apr 2010 17:28:50 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <201004212205.o3LM5pwQ019241@fs4113.wdf.sap.corp> <p06240887c7f52b14f905@[10.20.30.158]> <87fx2oxvua.fsf@mocca.josefsson.org> <p06240801c7f75b4444b0@[10.20.30.249]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:100423:paul.hoffman@vpnc.org::+M5PUTzOmkeM7Ty7:04AI
X-Hashcash: 1:22:100423:tls@ietf.org::Wqb/RrnY/3azYHpN:0qyw
X-Hashcash: 1:22:100423:ietf@ietf.org::qjhs02EZEKePOtPI:PitF
Date: Fri, 23 Apr 2010 17:28:48 +0200
In-Reply-To: <p06240801c7f75b4444b0@[10.20.30.249]> (Paul Hoffman's message of "Fri\, 23 Apr 2010 07\:13\:14 -0700")
Message-ID: <87d3xqgpcf.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: clamav-milter 0.95.3 at yxa-v
X-Virus-Status: Clean
Cc: ietf@ietf.org, tls@ietf.org
Subject: Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
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: Fri, 23 Apr 2010 15:29:05 -0000

Paul Hoffman <paul.hoffman@vpnc.org>; writes:

> 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.

I disagree with your description of people's objections.  My impression
is that people actually have been arguing precisely that the draft does
not solve the problem you describe.

My main concern with the document is that the problem you describe isn't
sufficiently well explained in the document itself for implementers and
application protocol designers to understand when use of the extension
is warranted.

If the PRNG is broken, your draft does not solve the many other places
in TLS that requires a working PRNG to provide a secure protocol: key
generation, CBC IV, random record padding, etc.  If you have 5 weak
links in a chain, making one of them stronger is not terribly relevant.

I sympathize with the goals of the draft, and I believe it would help in
theoretical proofs about entropy flows in secure protocols.

I don't believe implementing and enabling the draft would have any
overall positive effect on security on the Internet when all things are
considered, therefor I'm having a problem with it going on the standards
track.

/Simon