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 --
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Martin Rex
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Paul Hoffman
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Simon Josefsson
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Martin Rex
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Russ Housley
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Paul Hoffman
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Martin Rex
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Nikos Mavrogiannopoulos
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Martin Rex
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Marsh Ray
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Paul Hoffman
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Simon Josefsson
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Simon Josefsson
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Nicolas Williams
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Marsh Ray
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Nicolas Williams
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Martin Rex
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Dean Anderson
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Marsh Ray
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Michael D'Errico
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Dean Anderson
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Nicolas Williams
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Kemp, David P.
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Marsh Ray
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Nicolas Williams
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Marsh Ray
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Nicolas Williams
- [TLS] RNG vs. PRNG Michael D'Errico
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Dean Anderson
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Dean Anderson
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Kemp, David P.
- Re: [TLS] RNG vs. PRNG Marsh Ray
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Nicolas Williams
- Re: [TLS] RNG vs. PRNG Martin Rex
- Re: [TLS] RNG vs. PRNG Martin Rex
- Re: [TLS] RNG vs. PRNG Marsh Ray
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Dean Anderson
- Re: [TLS] Last Call: draft-hoffman-tls-additional… Sean Turner