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

Nicolas Williams <Nicolas.Williams@oracle.com> Fri, 23 April 2010 17:13 UTC

Return-Path: <Nicolas.Williams@oracle.com>
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 62E223A6829; Fri, 23 Apr 2010 10:13:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.6
X-Spam-Level:
X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[AWL=-1.002, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
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 0nIdyInEtE4z; Fri, 23 Apr 2010 10:13:50 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 1C7913A6A95; Fri, 23 Apr 2010 10:13:42 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3NHDNdu010253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Apr 2010 17:13:25 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3NEQixm005411; Fri, 23 Apr 2010 17:13:22 GMT
Received: from abhmt004.oracle.com by acsmt355.oracle.com with ESMTP id 203522491272042741; Fri, 23 Apr 2010 10:12:21 -0700
Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Apr 2010 10:12:20 -0700
Date: Fri, 23 Apr 2010 12:12:16 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Message-ID: <20100423171216.GV10389@Sun.COM>
References: <201004212205.o3LM5pwQ019241@fs4113.wdf.sap.corp> <p06240887c7f52b14f905@[10.20.30.158]> <87fx2oxvua.fsf@mocca.josefsson.org> <p06240801c7f75b4444b0@[10.20.30.249]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p06240801c7f75b4444b0@[10.20.30.249]>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: rcsinet15.oracle.com [148.87.113.117]
X-CT-RefId: str=0001.0A090203.4BD1D537.0083:SCFMA4539811,ss=1,fgs=0
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 17:13:52 -0000

On Fri, Apr 23, 2010 at 07:13:14AM -0700, Paul Hoffman wrote:
> 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.

Why can't you add text explaining that this particular extension (as
opposed to master-secret-input generally) can only be used with certain
cipher suites and is intended only for the purpose of strengthening the
maste secret computation.  Stay away from discussions of entropy, except
to explain that any random octet strings sent in cleartext contain zero
entropy relative to attackers (since they can see it passively).

Also, if you insist on saying that this extension can add entropy, can
you explain what it does that the existing client_random and
server_random don't do?

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

Irrelevant: if the random octets being sent don't add entropy (because
they are sent in cleartext) then this extension is completely orthogonal
to PRNG failures.

Incidentally, I think this I-D should specifically mention that the
extension is a client and server Hello extension, which will help
clarify for the reader that it is sent in cleartext (except for
renegotiation, but note that when used in renegotiation this extension
still adds no entropy if the same key exchange was used on the outer
negotiation).

> 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 do believe it's mostly harmless; I am concerned that 2^16 max octets
seems like a bit much, possibly a source of DoS attacks.  I believe it's
also useless.  As such I'm not opposed to it as an Experimental or even
Informational RFC.

I'm opposed to putting known-useless things on the Standards Track.  I
don't feel too strongly about that: if the IESG and IAB don't mind
putting known-useless things on the Standards Track, I can live with
that, provided, in any case, that the decision to do so explicitly
considers the utility of known-useless Standards.

Note that I believe that draft-hoffman-tls-master-secret-input _is_
useful, and should be on the Standards Track (even if initially there
are no uses of it also on the Standards Track).

Nico
--