[TLS] TLSrenego - current summary of semantics and possibilities

[Martin Rex <[e-mail]>]

Michael D'Errico wrote:
> 
> A client that wants protection from this attack MUST send the extension
> in its initial handshake.  Why don't you want to do that?

If there were only well-behaved servers out there, there would not
be any problem.

The default configuration of MSIE6 on WinXP to disable TLSv1.0, as well
as newer browsers providing a reconnect fallback to SSLv3-only ClientHello
indicate that there is an installed base of TLS servers that either
predates the SSLv3 internet-draft from Nov,18th 1996 or is defective.

There used to be a draft draft-pettersen-tls-interop-experience-xx.txt
(I have archived a -00 that expired oct-2006), which describes the
mess around spec non-compliance.  TLS-extensions are covered in section 4.

What it seems to indicate, in essence, is that the for maximum
interoperability with the installed base of (broken) servers out there,
you use a SSLv3 ClientHello with (0x03,0x00) in the client.version
and _no_ TLS extensions.

So conservative clients that do not want to implement reconnect
fallbacks may have a problem with the recommendation to always
use a TLS extension.


 
There are a number of things we would like to achieve with a fix:

  - provide a method for secure renegotiation in the future

  - deprecate the traditional renegotiation

  - provide a secure base for the (previously flawed) assumptions
    of servers when performing a renegotiation to request a
    client certificate.


in oder to achieve this, we should probably make the following
recommendations:

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

    If the presence of the TLS extension Renegotiation_Info causes the
    server to abort the TLS connection, then that
    server is not capable of secure renegotiation, and the TLS client
    should abort the Handshake with an error and close the connection
    in order to protect the client and the clients credential from
    abuse with servers that are still vulnerable to the TLS
    renegotiation problem.

 -  A TLS server (any protocol version, including SSLv3) should require
    the presence of a TLS extension Renegotiation_Info for _every_
    renegotiation handshake.

    If the TLS extension Renegotiation_Info is absent from the ClientHello
    received on an active TLS session, the server should abort the
    connection. (add Alert here)

    If the TLS extension Renegotiation_Info is present, then the TLS server
    MUST verify the contained verify_data of the client.finished message
    as known to the client with its own memorized client.finished
    message from the SecurityParameters of the current TLS connection state.

    If the comparison of the verify_data from the client.finished
    messages fails, the server MUST abort the connection.

    When the client's and the server's notion of the verify_data from
    the previous TLS session compare equal, the server MUST send back
    the TLS extension RenegotiationInfo with in a ServerHelloExtension
    containing the verify_data from the client.finished message and
    the verify_data from the server.finished message.

 -  A TLS client (any protocol version, including SSLv3) that receives
    the TLS extension Renegotiation_Info in a ServerHello extension
    must compare the extension data with its own SecurityParameters
    in the TLS connection state.

    If the Renegotiation_Info with empty extension_data is received
    on a client's initial TLS handshake, everything is fine

    If the Renegotiation_Info with empty extension_data is received
    on an active TLS session, the client MUST abort the handshake
    with an error and close the connection.

    If the Renegotiation_Info with non-empty extension_data is received
    on a client's initial TLS handshake, the client MUST abort the handshake
    with an error and close the connection.

    If the Renegotiation_Info with non-empty extension_data is received
    on a client's renegotiation handshake, the client MUST compare the
    contained verify_data of the server-memorized client.finished and
    server.finished messages with its own memorized verify_data for
    both finished messages in the SecurityParameters of the TLS connection
    state for the current session.
      - if they compare equal, everything is fine
      - if they do not match, the client MUST abort the handshake and
        close the connection.



It is possible that a TLS client may not want to assert the TLS extension
Renegotiation_Info in an initial ClientHello because of interoperability
concerns with an installed base of not-quite-spec-compliant servers.

What other strategies could be used on the initial handshake on a 
connection with lesser side effects that a TLS extension Renegotiation_Info
with empty extension_data?


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

   - Assign one (or two) specific ciphersuite IDs that the client
     can include in the ciphersuites list which signal the clients
     notion of the connection state (initial vs. renegotiation)
     to the server.

   - Assign one (or two) compression algorithm IDs that the client
     can include in the supported compression algorithms list which
     signal the clients notion of the connection state (initial vs.
     renegotiation) to the server.

I assume that a Client->Server signalling through a special cipher suite
might be the easy to implement for clients and expect that it has the
least side effects on handshakes with old servers.

Fancy compression algs might be less digestable to old servers.


Both of these (one or two fany ciphersuites in the ciphersuite
list of the client) can only be used for signalling from client
to server, not in the direction server to client.


What could be used to signal from the server to the client that the
client should send the TLS extension Renegotiation_Info in the
ClientHello of a renegotiation handshake if the client does not
want to send the TLS extension in the initial handshake of a
connection?

We could define a new TLS handshake message "RenegotiationRequest"
to be sent instead of a "HelloRequest".  This would be an option for
those servers, that will abort the handshake and connection
if the client does not send the TLS extension Renegotiation_Info.

The purpose of a RenegotiationRequest would be to encourage clients to
send the TLS extension Renegotiation_Info, in order to keep existing
usage scenarios usable.  The message itself is not protected, but
that doesn't matter.  The servers decision for success or failure
of the renegotiation depends only and entirely on the use of
the TLS extension Renegotiation_Info in the renegotiation handshake
and successful verification of the verify_data from the 
client.finished handshake message of the active TLS session.



-Martin