Re: [TLS] TLS renegotiation issue

[Martin Rex <[e-mail]>]

Nicolas Williams wrote:
> 
> On Thu, Nov 05, 2009 at 07:16:02PM +0100, Martin Rex wrote:
> > Nicolas Williams wrote:
> > > You can't use the client.random and server.random as channel bindings.
> > 
> > I'm trying to use terminology that is already in the TLS specs.
> > The generic term "channel bindings" is a little bit to fuzzy for
> > my taste, and the original use of channel bindings in GSS-API
> > is not cryptographically secure.
> 
> I understand.  The spec will just have to be updated to say that the
> finished messages (or at least the client one) are to be exported to
> applications.

Huh -- wrong topic?

Eric's proposal to make renegotiation secure does not need any
API-level changes, everything is completely internal to the
TLS protocol engine.

What you're looking for might be necessary for application-level
channel bindings, but that is a different topic.

I don't mind discussing this, but I would appreciate if you identify
the topic/solution that you're discussing.  ;-)


> 
>                                 I perfectly understand, and _share_, the
> desire to use existing interfaces where possible.  In this case there is
> no such interface (in some TLS APIs apps could parse the TLS record
> layer and heuristically find the record that contains the protected
> client Finished message, but that's... not really an interface, not what
> we wnat, and not reliably available everywhere).

On the network, the finished messages are protected under the negotiated
ciphersuite.  Eric's proposal used the verify_data in its decrypted
form, and I thought you were asking for these as well.


> 
> We've looked at this problem many times before, and this is always the
> conclusion that we've come to.  I really wish that TLS 1.2 had made the
> client Finished messages part of the exported security parameters (I
> really wish I'd thought to make sure that 1.2 did that).  But then,
> making the 1.2 spec say this is not enough: installed base inertia is
> what makes it hard to ensure that Finished messages are exported.

Exported security parameters?

Your desire to get your hands on the finished message from the
App layer for channel binding purposes is an API issue.

The TLS-specs describe only bits-on-the-wire, protocol semantics
and TLS session state management.  The TLS specs are entirely
silent on API issues.  (The IETF does not do APIs, and GSS-API
is an exception.)


-Martin