Re: [TLS] Redefine Finished message for TLS 1.3 ?

Nicolas Williams <Nicolas.Williams@sun.com> Sun, 15 November 2009 02:12 UTC

Return-Path: <Nicolas.Williams@sun.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 A882E3A67B8 for <tls@core3.amsl.com>; Sat, 14 Nov 2009 18:12:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.017
X-Spam-Level:
X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 vft9gO-U96tb for <tls@core3.amsl.com>; Sat, 14 Nov 2009 18:12:36 -0800 (PST)
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 3DC363A6784 for <tls@ietf.org>; Sat, 14 Nov 2009 18:12:35 -0800 (PST)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAF2D39Z026007 for <tls@ietf.org>; Sun, 15 Nov 2009 02:13:03 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nAF2D3GF033062 for <tls@ietf.org>; Sat, 14 Nov 2009 19:13:03 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nAF1rvWS020711; Sat, 14 Nov 2009 19:53:57 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAF1rvcN020710; Sat, 14 Nov 2009 19:53:57 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Sat, 14 Nov 2009 19:53:57 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Nelson B Bolyard <nelson@bolyard.me>
Message-ID: <20091115015357.GP1105@Sun.COM>
References: <20091112181844.GE1105@Sun.COM> <200911122036.nACKa96m016227@fs4113.wdf.sap.corp> <20091112203847.GL1105@Sun.COM> <20091113082235.C55F469F381@kilo.networkresonance.com> <20091113164608.GT1105@Sun.COM> <4AFF0153.3090005@bolyard.me> <20091114213353.GN1105@Sun.COM> <4AFF33D2.4050705@bolyard.me>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4AFF33D2.4050705@bolyard.me>
User-Agent: Mutt/1.5.7i
Cc: tls@ietf.org
Subject: Re: [TLS] Redefine Finished message for TLS 1.3 ?
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: Sun, 15 Nov 2009 02:12:37 -0000

On Sat, Nov 14, 2009 at 02:48:50PM -0800, Nelson B Bolyard wrote:
> On 2009-11-14 13:33 PDT, Nicolas Williams wrote:
> > On Sat, Nov 14, 2009 at 11:13:23AM -0800, Nelson B Bolyard wrote:
> >> Does the Working Group share interest in redefining the Finished message
> >> computation for TLS 1.3?
> > 
> > I doubt it.  Once the use of hello extensions is demonstrated to work
> > even for critical cases and when server hello extensions are needed,
> > then there's no need to change to using an unsignalled fix as in your/my
> > proposals.
> 
> Well, I'd consider use of the version number 0x0304 (for SSL 3.4, which
> is TLS 1.3) in the client hello to be an effective signal.

Well, yes, but that wasn't your proposal on Sept 29, and it wasn't mine
this past week.

> I hope there will be more responses, so that we can get a sense of consensus
> for or against this idea.

I think the consensus is probably to go with EKR's fix as is.  Note that
my proposed fix could actually also be deployed for SSLv3 systems, IF it
makes sense that they could get patched more easily than upgraded (which
I doubt, but then, I've no data to go on).

Once EKR's fix is deployed there will be no point to do a TLS 1.3 just
to have an alternative fix -- why bother?

Nico
--