Re: [TLS] TLS renegotiation issue

[Nicolas Williams <[e-mail]>]

On Thu, Nov 05, 2009 at 09:21:44PM +0100, Martin Rex wrote:
> 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?

Not really.

Eric's view seems to be that the TLS spec should say nothing about this.

I think it should, for the simple reason that it will help prevent this
sort of problem in the future.

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

You misunderstood the parenthetical.  The point was that one might think
that apps could get at the Finished messages without help, but in
reality they could only get at the protected Finished message, and only
if the TLS API was such that the apps could see the TLS record protocol
directly, and then only by implementing a heuristic -- all of which is
something we _don't_ want.  I wrote that parenthetical to preempt anyone
saying "why don't you just do [what the text in paren. talked about]?".

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

Wrong.  The GSS-API is NOT the only exception.  There's also SCTP, and
probably a number of otheres (heck, even IDNA has an abstract API).

Nico
--