Subject: [TLS] Implementation Experience

From: Michael D'Errico <[email-masked]>
Date: Tue, 17 Nov 2009 15:17:16 -0800

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.

---

From: "Robert Dugal" <[email-masked]>
Date: Wed, 18 Nov 2009 06:31:28 -0500

Other implementors may not experience the same code size cost as your findings.
Our product already implements several TLS extensions and has all the framework in place to add more.
Adding the extension support itself is trivial. Tieing renegotiation to the extension is trivial too.
We also have a framework for testing extensions. 
I suspect the most code I would have to write is test and sample code.

-- 
Robert Dugal		Senior Software Developer
Certicom Corp.		A Subsidiary of Research In Motion 
[email-masked]
direct        905.501.3848
fax             905.507.4230
www.certicom.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael D'Errico
Sent: Tuesday, November 17, 2009 6:17 PM
To: [email-masked]
Subject: [TLS] Implementation Experience

Mike

    struct {

for a total of 26 bytes added to the handshake hash.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 18 Nov 2009 08:12:40 -0800

> I suspect the most code I would have to write is test and sample code.

My code already supports extensions, and even so, the RI proposal
required a lot more code than the alternative presented.  That is
a solid finding.  I did nothing different than I always do to
implement both; I did not try to influence the lines-of-code to
make the alternative look more attractive.

You are fortunate to already have extension support, but we need to
be considerate to those that don't.  It probably took you a long
time to put that framework in place, refine it, test it, etc.  Did
you do that work at your leisure?  Or were you faced with a ticking
time bomb of an actively-exploitable serious security problem you
needed to patch?

Mike