Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt

From: Martin Rex <[email-masked]>
Date: Tue, 24 Nov 2009 02:14:53 +0100 (MET)

>
> http://www.ietf.org/id/draft-mrex-tls-secure-renegotiation-00.txt

One of the first feedback I received indicates that the amount of
details in the document might make it appear much more complicated as it is.

The idea of my proposal is to keep the changes to an absolute
minimum (but offer secure renegotiation to all usage scenarios
in the installed base).

Solution brief:

  1.) memorize verify_data from Client.Finished and Server.Finished
      in ConnectionState of current session

  2.) on renegotiation handshakes, add memorized verify_data into
      handshake message hash to establish cryptographic binding

  3.) C->S signaling with special cipher suite ID

  4.) S->C signaling through highest bit in ServerHello.server_version

additional explanation:

1.) is something that TLS extension RI needs as well

2.) is TLS extension RI on a diet and in failSAFE mode:
      - no fancy extension wrapping,
      - no re-send of the previous finished messages over the network
      - identical cryptographic properties, as described here:
    http://www.ietf.org/mail-archive/web/tls/current/msg04194.html

TLS extension RI signals by presence of the extension,
my proposal signals extension-less through existing protocol
elements  3) is compatible with SSLv3 and SSLv2 ClientHello,
4) is compatible with SSLv3 ServerHello

3.) self-explaining, I hope

4.) I'm not changing the protocol version numbers anywhere in the
    protocol, just hitch-hiking an unused bit in
    ServerHello.server_version while traveling the network

    that hitch-hiking bit must be removed for all protocol-version
    related processing of server_version and not appear anywhere else,
    neither on the network and not in the code,
    beside the code that assembles the ServerHello PDU on the server
    and the code that parses the ServerHello PDU on the client.

    It will only be returned to clients sending (3).

-Martin