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

[Nicolas Williams <Nicolas.Williams at sun.com>]

On Tue, Nov 10, 2009 at 01:37:27PM -0600, Steve Dispensa wrote:
> 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.

I guess we'll see whether the need to interop with broken servers (which
are probably broken forever, and therefore vulnerable forever) is
important enough that implementors will have to include a knob for
whether to send this extension on initial negotiations.  I consider the
fact that it will break such broken servers a feature, but one must be
realistic also.

Nico
--