Re: [TLS] TLS renegotiation issue

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> Martin Rex wrote:
> >
> > Technically there is no
> > limit on the number of renegotiations, so a simple pointer
> > only one TLS session into the past does not seem sufficient
> > for that purpose.
> 
> I agree, the concept of "first handshake on the socket" is a bit
> nebulous from the perspective of the TLS spec.

For the secure renegotiation, the pointer exactly one TLS session
into the past seems perfectly sufficient to me.

Solving the nebulous concept of "first handshake on the socket"
is something that Larry wants a solution for, and which needs
a different approach.

The "secure naming" of a TLS connection has much more to do with
API semantics than with TLS wire-protocol and TLS session state.

TLS renegotiation does IMHO also interfere with the TLS PRF
(aka TLS-extractors), so that applications can not call it
at arbitrary points in their communication with a peer when
there might be a renegotiation between the point in time
when the client app calls in and when the server app calls it.


> 
> The approach our proposal took was to work off of the "most recent
> previous finished message" over the underlying transport.

The "secure random challenges" in a TLS handshake that protect
agains replay are the client.random and server.random.
Admittedly they're larger (2*32 octets, fixed size) than the
finished message (usually 12 octets, but depends on ciphersuite
according to rfc5246 7.4.9.)

The client.random and server.random of a connection are already
part of the official SecurityParameters (rfc5246 6.1.), but
the finished message is not.

-Martin