Re: [TLS] TLS renegotiation issue

Martin Rex <mrex@sap.com> Thu, 05 November 2009 23:51 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 81F6F3A681B for <tls@core3.amsl.com>; Thu, 5 Nov 2009 15:51:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.027
X-Spam-Level:
X-Spam-Status: No, score=-6.027 tagged_above=-999 required=5 tests=[AWL=0.222, 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 NXr1YEvIhtrK for <tls@core3.amsl.com>; Thu, 5 Nov 2009 15:51:38 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 4D8513A67A8 for <tls@ietf.org>; Thu, 5 Nov 2009 15:51:38 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA5NpxCv014613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2009 00:51:59 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911052351.nA5Npxai022736@fs4113.wdf.sap.corp>
To: Nicolas.Williams@sun.com (Nicolas Williams)
Date: Fri, 6 Nov 2009 00:51:59 +0100 (MET)
In-Reply-To: <20091105230343.GO1105@Sun.COM> from "Nicolas Williams" at Nov 5, 9 05:03:44 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
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 23:51:39 -0000

Nicolas Williams wrote:
> 
> On Thu, Nov 05, 2009 at 10:16:11AM -0800, Eric Rescorla wrote:
> > I now have a draft extension up at:
> > 
> > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt
> > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml
> > 
> > Comments welcome.
> 
> More comments:
> 
>  - Consider an implementation like Windows' SSPI-based implementation.
>    Or, for that matter, the old GGF (Global Grid Forum) GSS-API
>    interface to TLS.

This strikes me as really odd!

Btw. does GGF really require renegotiation?  What is so impossible
about asking for a client cert in the initial TLS handshake?


I read your message to mean that applications based on architectures
like SSPI and GGF will need to modify their code INDEPENDENTLY to
how we solve the problem to avoid the security problem as well
as to adopt the solution.

Why do you insist that we make the change in a fashion that
caters a particular API?


I would not mind if those TLS implementers with the GGF and SSPI
use the terminology and function parameters they formerly called
"channel bindings" (AFAIK SSPI doesn't have channel bindings)
to pass along the finished messages described in Erics document.

I am certainly opposed to adopting one particular API's
terminology and confuse other API architectures where there
already is an established term for the piece of information
that we want to carry over between an existing TLS session
and a new TLS session.


What I definitely do NOT want here, is make that new box
(the TLS extension for secure renegotiation) officially available
to the discretion of the application caller, since those
applications just demonstrated to act based on extremely
flawed assumptions.  If you want to do that for your particular
implementation, OK.  I definitely do not want to see this
being recommended or encouraged by the TLS spec.

Once bitten, twice shy.


>
> That is, I propose that you re-shape the proposal as a generic channel
> binding facility for TLS.  The actual changes to the proposal are fairly
> minor: a) the proposed extension needs to carry an opaque octet string
> of variable length, b) the server should echo a trivial transformation
> of the client-provided string.

So for this particular issue we're discussing here, those APIs should
build solutions to pass down the security context handle of the
"current" TLS session to handshake operations performed by the "pending"
TLS session, so that these can retrieve and verify the relevant
verify_data structures.


For OpenSSL-style APIs the TLS session renegotiation happens
(or is denied) transparently on the same SSL session handle.



-Martin