[TLS] Implementation Experience

[Michael D'Errico <mike-list at pobox.com>]

I have some hard numbers to share regarding implementation
of the RI extension and the alternate proposal given below.

I initially implemented the RI extension in my code and
based on the CVS logs, the net addition of code was 248
lines of C++.

Just this morning I ripped out the RI extension and instead
implemented the alternate proposal.  Based on the CVS logs
there was a net decrease of 91 lines of code.

That means RI requires 58% MORE CODE in a codebase that
already fully supports TLS extensions.

In addition, RI practically requires implementing fallback
code, which I did not add, so I would bet RI requires at
least double the amount of code as this alternate proposal,
and possibly a lot more given the myriad possible fallback
scenarios.

I will be installing this change on my test server shortly
for anyone to test against.

Mike

-----------------------------------------------------------
Alternate proposal to RI:


  - Client includes a special cipher suite as the first
    in its cipher suite list.  The value chosen for
    testing: 0xBFFF (the last of the "Standards Action"
    cipher suites -- I'm pretty sure I've seen 0xFEFF
    used in the wild)

  - Upon seeing this marker, the server does the following:

     a) sets the high bit of the low byte of the version
        returned in ServerHello -- this indicates to the
        client that the server recognized the special
        cipher suite -- the record layer version uses
        the normal version number without the high bit
        set; Examples:
            SSLv3:   0x0380
            TLS 1.0: 0x0381
            TLS 1.1: 0x0382
            TLS 1.2: 0x0383
     b) adds to the Handshake Hash the PreviousVerifyData
        structure (see below) immediately following
        ServerHello; only the PreviousVerifyData is added,
        it is not wrapped to look like a handshake message
        with a type and length.

  - Upon noticing the high bit of the low byte of the
    server's version being set, the client does the
    following:

    a) resets the high bit of the low byte of the version
       to be used for the record layer version
    b) adds to the Handshake Hash the PreviousVerifyData
       structure immediately following ServerHello

A server would obviously not renegotiate if the magic cipher
suite is not present in the renegotiation ClientHello.  If
it is present but is actually a proxied initial handshake
through a MITM, the PreviousVerifyData used by client and
server will be different and thus the handshake will fail and
the attack prevented.

PreviousVerifyData structure:

   struct {
      opaque previous_client_verify_data<0..255>;
      opaque previous_server_verify_data<0..255>;
   } PreviousVerifyData;

The PreviousVerifyData on the initial handshake would be
just two zero bytes, one for each of the lengths of the
opaque vectors.  When renegotiating, it will look like:

   0x0C [12 client verify data bytes] 0x0C [12 server bytes]

for a total of 26 bytes added to the handshake hash.