Re: [TLS] What would be the point of removing signalling in TLS 1.3?

Stefan Santesson <stefan@aaa-sec.com> Fri, 27 November 2009 07:28 UTC

Return-Path: <stefan@aaa-sec.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 855D63A6840 for <tls@core3.amsl.com>; Thu, 26 Nov 2009 23:28:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.685
X-Spam-Level:
X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 nhLZt20UIgf9 for <tls@core3.amsl.com>; Thu, 26 Nov 2009 23:28:29 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by core3.amsl.com (Postfix) with ESMTP id 9C6B63A6808 for <tls@ietf.org>; Thu, 26 Nov 2009 23:28:28 -0800 (PST)
Received: from s128.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id D28662926DF for <tls@ietf.org>; Fri, 27 Nov 2009 08:28:23 +0100 (CET)
Received: (qmail 29427 invoked from network); 27 Nov 2009 07:28:21 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <nelson@bolyard.me>; 27 Nov 2009 07:28:21 -0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Fri, 27 Nov 2009 08:28:20 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Nelson B Bolyard <nelson@bolyard.me>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <C7353E24.6BA8%stefan@aaa-sec.com>
Thread-Topic: [TLS] What would be the point of removing signalling in TLS 1.3?
Thread-Index: AcpvMzGfI6ileBHjWkOZco0OwzijXg==
In-Reply-To: <4B0F5E6D.2050904@bolyard.me>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [TLS] What would be the point of removing signalling in 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: Fri, 27 Nov 2009 07:28:30 -0000

Thanks Nelson for writing it out.
This was exactly what I meant.

/Stefan

On 09-11-27 6:06 AM, "Nelson B Bolyard" <nelson@bolyard.me> wrote:

> On 2009-11-26 13:22 PST, Marsh Ray wrote:
>> Stefan Santesson wrote:
>>> If you fix the Finished message calculation, making it immune to the
>>> renegotiation attack, and making it the standard Finished calculation for
>>> 1.3.... Then why would you need to signal that you are using the standard
>>> Finished calculation?
>> 
>> So that clients and servers can be upgraded over a period of time
>> without causing interoperability problems.
> 
> But clients and servers that are written to speak 1.3 (which doesn't exist
> today) would be written to do the right thing from day 1, when they
> negotiate version 1.3.  There would be no "upgrade over a period of time"
> for clients and servers that negotiation version 1.3.
> 
> I'd propose the use of RI in 1.3 this way.
> 
> A 1.3 client that also implements lesser versions MUST send RI in the client
> hello, in case the server does not implement 1.3, but implements some lesser
> version.
> 
> A 1.3 server that also implements lesser versions MUST send RI in the server
> hello when the client hello asks for a version less than 1.3 and the server
> hello agrees to negotiate a version less than 1.3.
> 
> A 1.3 server that receives a client hello bearing version 1.3 (or greater)
> NEVER returns RI in the server hello when the server hello negotiates
> version 1.3 (or greater).
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls