Re: [TLS] TLS renegotiation issue

[Martin Rex <mrex at sap.com>]

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