Re: [TLS] TLSrenego - current summary of semantics and possibilities

[Steve Dispensa <dispensa at phonefactor.com>]

On 11/10/09 1:28 PM, "Martin Rex" <mrex at sap.com> wrote:
>   - if a TLS client (any protocol version, including SSLv3) performs
>     renegotiation (i.e. sends a ClientHello over an established
>     TLS session with a ciphersuite other than TLS_NULL_WITH_NULL_NULL),
>     then it SHOULD always and unconditionally use the TLS extension
>     Renegotiation_Info containing the verify_data of the client.finished
>     handshake message from the active TLS session,
>     The TLS client should do that even when it did not send the
>     TLS extension Renegotiation_Info with and empty extension data
>     in the initial TLS handshake on a connection!
> 
>     Lacking application level re-connect provisions for forward-incompatible
>     SSL/TLS servers, a TLS client might not want to sent the TLS extension
>     in the initial ClientHello of a connection.

This was discussed a bit at the Sept. 29 meeting. I had originally suggested
that the extension need not be present during initial negotiations at all,
but it was pointed out that network management systems might want to
inventory patched clients and servers.

> Overloading ("abusing") the semantics of other regular elements
> of an SSL/TLS handshake that have a lesser likelihood to upset
> legacy servers.

This is an interesting potential solution to the network monitoring problem,
if nothing else. 

 -Steve