Re: [TLS] TLS renegotiation issue

Nicolas Williams <Nicolas.Williams@sun.com> Thu, 05 November 2009 23:14 UTC

Return-Path: <Nicolas.Williams@sun.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 BAD223A67E2 for <tls@core3.amsl.com>; Thu, 5 Nov 2009 15:14:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.014
X-Spam-Level:
X-Spam-Status: No, score=-6.014 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 mFuVIU5jWzOb for <tls@core3.amsl.com>; Thu, 5 Nov 2009 15:14:52 -0800 (PST)
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 396253A67DF for <tls@ietf.org>; Thu, 5 Nov 2009 15:14:52 -0800 (PST)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA5NFEjb027552 for <tls@ietf.org>; Thu, 5 Nov 2009 23:15:15 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nA5NFE1D039993 for <tls@ietf.org>; Thu, 5 Nov 2009 16:15:14 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA5N3iR8009645; Thu, 5 Nov 2009 17:03:44 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5N3imO009644; Thu, 5 Nov 2009 17:03:44 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Thu, 5 Nov 2009 17:03:44 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20091105230343.GO1105@Sun.COM>
References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <d3aa5d00911051016p7a0cc508q2090b86de30a50d5@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d3aa5d00911051016p7a0cc508q2090b86de30a50d5@mail.gmail.com>
User-Agent: Mutt/1.5.7i
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS renegotiation issue
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: Thu, 05 Nov 2009 23:14:53 -0000

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.

   In such an implementation each TLS connection is a distinct "security
   context".  So in the re-negotiation case there are two distinct
   negotiations, each being an application-driven API (i.e., in each
   case the application calls functions like the GSS-API
   GSS_Init_sec_context() and GSS_Accept_sec_context()).

   So how would an implementor with such an API implement your proposal?
   Like so:

   1) Add a function to extract the Finished messages from a TLS
      "security context".  This is trivial to do: it's just a new
      function, an accessor of security contexts.

   2) Add a function or input to the init/accept_sec_context functions
      by which to pass in, to a new "security context", the Finished
      messages of another TLS "security context".  This can't easily be
      done as a new accessor-type function -- it has to be a new
      function argument, which... can't be done, so that one has to
      simply add new versions of the init/accept_sec_context functions.

   But wait!  The SSPI/GSS-API already have the (2)!  And we call it a
   "channel binding" input.

   You can see where I'm going with this.  It will help keep existing
   APIs clean if you just stick to the RFC5056 model and call this
   "channel binding".

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.

Nico
--