IETF Logo Mail Archive

Re: [TLS] draft-ietf-tls-renegotation: next steps

Martin Rex <mrex@sap.com> Wed, 16 December 2009 20:32 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 0C7753A6A55; Wed, 16 Dec 2009 12:32:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.194
X-Spam-Level:
X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 r4PVQkeqOJm3; Wed, 16 Dec 2009 12:32:55 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id E701D3A6918; Wed, 16 Dec 2009 12:32:54 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBGKWaAZ006771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 21:32:36 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912162032.nBGKWZwc016244@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com
Date: Wed, 16 Dec 2009 21:32:35 +0100
In-Reply-To: <4B293E48.406@extendedsubset.com> from "Marsh Ray" at Dec 16, 9 02:08:40 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: tls@ietf.org, ietf@ietf.org
Subject: Re: [TLS] draft-ietf-tls-renegotation: next steps
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: Wed, 16 Dec 2009 20:32:56 -0000

First, we need to fix the Definition of the TLS_RENEGO_PROTECTION_REQUEST:

This cipher suite value is the Client to Server signal that the client
is updated and asks to apply the strict rules of secure renegotiation
applied to the current handshake -- no excuses.

If SCSV is received by a server on an initial handshake that does
not contain a renegotiation_info TLS extension, then the server
should apply the same semantics as if it had received an empty
TLS extension RI in that ClientHello.


Concerning the question what a client should send on a backwards
interoperable renegotiation handshake:

The rule is "if you can't be good, at least be good at it.".

That means if the clients configuration permits old-style renegotiation,
then he should NOT try fancy new tricks with that old server on the
renegotiation handshake that he didn't do on the initial handshake.

i.e. if the client had sent TLS extensions on the initial handshake,
there is no problem with _sending_ TLS extension RI on the renegotiation
handshake with the old server.

However, if the client did _not_ use TLS extensions (but SCSV) on
the initial handshake with an old server, then there are only
to sensible options for the client on renegotiation:
  (a) abort when the client doesn't allow old-style renegotiation
  (b) send an extension-less ClientHello with MCSV on renegotiation.


-Martin

v2.23.0 | Report a Bug | By Email