Re: [TLS] TLS renegotiation issue

[Nicolas Williams <[e-mail]>]

On Thu, Nov 05, 2009 at 08:29:28PM +0100, Martin Rex wrote:
> Nicolas Williams wrote:
> > 
> > Initial comments based on a brief skim:
> > 
> >  - Please add a normative reference to RFC5056.
> 
> I admit to not know what that exactly means, but it sounds wrong.
> 
> It is perfectly possible to write this document in a fashion that
> an implementor does NOT NEED to read rfc5056, and therefore I
> would strongly prefer to keep it that way.

Referencing RFC5056 wouldn't so much be to provide guidance to
implementors as to say "this document conforms to RFC5056".

> >  - There's no real need for the ServerHello to include both of the
> >    Finished messages from the outer TLS connection.  (I think there's no
> >    real need for the ServerHello to include either of them, actually,
> >    but I've not thought enough about that.)  But it's OK as is, of
> >    course.
> 
> The Server should send back something different than on initial
> connect in order to indicate to the client that it is convinced
> this is a renegotiation rather than an initial handshake.

Indeed, it must send something.  Even one bit will do -- that was my
point.

> Sending back the verify_data from Server finished seems fair to me.

I agree -- that allows the client to verify that the server did
something more than agree.  There's no point in the server sending back
the client's Finished message though -- that adds no value and wastes
space on the wire (very little, granted).

> >    (In practice there's probably never more than one outer and one inner
> >    handshake, right?)
> 
> Technically, there can NEVER be more than two, as required by the TLS
> spec (there is only one current and one pending) so technically, the
> existing proposal is referencing the "outer-most" TLS session.

Interesting.

> >  - There is a way for clients to protect themselves even when servers
> >    don't implement this extension:
> 
> I would hope there is a way, but I have not seen one so far!
> 
> There are actually two different scenarios:
> the one I suggested where both sides, client and server perform
> a renegotiation, and the one described by Marsh, where a clients
> initial TLS handshake is proxied into a renegotiation for the
> server.

Ah.  I was considering only one of those attacks.  You're correct, there
is no workaround short of fixing the protocol.

> >  - Might as well update RFC5246 to indicate that the Finished messages
> >    for any connection MUST be exported to applications.  Better get this
> >    done now.
> 
> I haven't sufficiently thought about this to like it.
> 
> Adding the finished messages to the renegotiation handshake
> is fine, because they have originally exchanged under the protection
> of the currently active ciphersuite, so this should have zero impact.

For an implementation like Microsoft's SSPI-based implementation TLS
that might not be true, since there each TLS connection is represented
by a separate "security context" -- for such an implementation the fix
requires that the application help the implementation link those
security contexts.

> You're asking to make something available that has not been previously
> available to the application.  This might be harmless, but I don't know.

How could it not be harmless?  What damage could ensue from making the
Finished messages of a TLS connection available to the application?
Remember: there are cipher suites that provide only integrity
protection, therefore Finished messages must not leak any information
about the master secret (and indeed, they do not, module the
cryptographic strength of the relevant algorithms used in the Finished
message construction).

Nico
--