Re: [TLS] TLS renegotiation issue

[Nicolas Williams <Nicolas.Williams at sun.com>]

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
--