Re: [TLS] TLS renegotiation issue

Martin Rex <mrex@sap.com> Thu, 05 November 2009 19:29 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 59E383A69EF for <tls@core3.amsl.com>; Thu, 5 Nov 2009 11:29:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.009
X-Spam-Level:
X-Spam-Status: No, score=-6.009 tagged_above=-999 required=5 tests=[AWL=0.240, 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 Dp6T7nTDpFbY for <tls@core3.amsl.com>; Thu, 5 Nov 2009 11:29:08 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 2AF323A6994 for <tls@ietf.org>; Thu, 5 Nov 2009 11:29:07 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA5JTSVM012418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2009 20:29:29 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911051929.nA5JTSaR007035@fs4113.wdf.sap.corp>
To: Nicolas.Williams@sun.com (Nicolas Williams)
Date: Thu, 5 Nov 2009 20:29:28 +0100 (MET)
In-Reply-To: <20091105184615.GG1105@Sun.COM> from "Nicolas Williams" at Nov 5, 9 12:46:15 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: ekr@rtfm.com, tls@ietf.org
Subject: Re: [TLS] TLS renegotiation issue
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: Thu, 05 Nov 2009 19:29:09 -0000

Nicolas Williams wrote:
> 
> Initial comments based on a brief skim:
> 
>  - Please add a normative reference to RFC5056.

I admit to not know what that exactly means, but it sounds wrong.

It is perfectly possible to write this document in a fashion that
an implementor does NOT NEED to read rfc5056, and therefore I
would strongly prefer to keep it that way.

> 
>  - There's no real need for the ServerHello to include both of the
>    Finished messages from the outer TLS connection.  (I think there's no
>    real need for the ServerHello to include either of them, actually,
>    but I've not thought enough about that.)  But it's OK as is, of
>    course.

The Server should send back something different than on initial
connect in order to indicate to the client that it is convinced
this is a renegotiation rather than an initial handshake.

Sending back the verify_data from Server finished seems fair to me.


> 
>  - You call for each TLS handshake to bind to the one immediately
>    outside it.
> 
>    Would it be better to bind to the outer-most one instead?

I prefer it the way it is currently described, referencing the
predecessor.

> 
>    (In practice there's probably never more than one outer and one inner
>    handshake, right?)

Technically, there can NEVER be more than two, as required by
the TLS spec (there is only one current and one pending) so technically,
the existing proposal is referencing the "outer-most" TLS session.

You were probably asking for the first TLS-handshake on a connection?

The existing proposal looks like less code to me.

> 
>  - There is a way for clients to protect themselves even when servers
>    don't implement this extension:

I would hope there is a way, but I have not seen one so far!

There are actually two different scenarios:
the one I suggested where both sides, client and server perform
a renegotiation, and the one described by Marsh, where a clients
initial TLS handshake is proxied into a renegotiation for the
server.

Without a change of the server, the client has certain difficulties
to determine whether it is participating in an initial TLS handshake
or being proxied into a renegotiation in Marsh's scenario.

There are certain safeguards a client can apply (but which are not
currently advised by the spec, so are unlikely to be implemented
in existing clients.

A TLS client could insist on a server credential to not change
during a renegotiation.  That helps for my scenario, but
not for that of Marsh.

A TLS client should probably not accept a HelloRequest and neither
a CertificateRequest message on a server-anonymous TLS session
(DH_anon).


> 
>  - Might as well update RFC5246 to indicate that the Finished messages
>    for any connection MUST be exported to applications.  Better get this
>    done now.

I haven't sufficiently thought about this to like it.

Adding the finished messages to the renegotiation handshake
is fine, because they have originally exchanged under the protection
of the currently active ciphersuite, so this should have zero impact.

You're asking to make something available that has not been previously
available to the application.  This might be harmless, but I don't know.

-Martin