Re: [TLS] Updated draft

Martin Rex <mrex@sap.com> Fri, 18 December 2009 17:45 UTC

Return-Path: <mrex@sap.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 9D6A93A6983 for <tls@core3.amsl.com>; Fri, 18 Dec 2009 09:45:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.196
X-Spam-Level:
X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 H71+SwlsciO7 for <tls@core3.amsl.com>; Fri, 18 Dec 2009 09:45:47 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id AEE863A6930 for <tls@ietf.org>; Fri, 18 Dec 2009 09:45:46 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBIHjQFG005593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Dec 2009 18:45:26 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912181745.nBIHjPN5028573@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com
Date: Fri, 18 Dec 2009 18:45:25 +0100
In-Reply-To: <4B2BAFAC.9020501@extendedsubset.com> from "Marsh Ray" at Dec 18, 9 10:37:00 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Cc: rdugal@certicom.com, tls@ietf.org
Subject: Re: [TLS] Updated draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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, 18 Dec 2009 17:45:47 -0000

Marsh Ray wrote:
> 
> Currently, the SCSV achieves its primary objective with a very simple
> definition. It has "exactly the same semantics as an empty
> 'renegotiation_info' extension".

How about

TLS_RENEGO_PROTECTION_REQUEST is a request from the client to the
server to perform a secure handshake and confirm this by sending
TLS extension RI in ServerHello.

This will also fix the awkward disconnect between the symbolic name of
the SCSV and the current description of its semantics.

-Martin