A proposal to countermeasure BEAST attack

I posted the proposal to countermeasure the BEAST attack in Bug 665814 at Bugzilla@Mozilla. For quick reference, I copy it in the blog:

Xuelei Fan 2011-07-20 20:35:42 PDT  Comment 59:

One significant drawback of the current proposed countermeasure
(sending empty application data packets) is that the empty packet
might be rejected by the TLS peer (see comments #30/#50/others:  MSIE
does not accept empty fragments, Oracle application server (non-JSSE)
cannot accept empty fragments, etc.)

We've been looking at a slightly different countermeasure that should
comply with the TLSv1.0/SSLv3.0 specifications, and likely won't break
implementations. Would you please review the following proposal?
If this is sound, this might avoid the empty packet issue, and the
switches necessary to configure it.

Looking at the spec of TLS, the block-ciphered structure is defined as:

       block-ciphered struct {
           opaque content[TLSCompressed.length];
           opaque MAC[CipherSpec.hash_size];
           uint8 padding[GenericBlockCipher.padding_length];
           uint8 padding_length;
       } GenericBlockCipher;

This implies that if the TLSCompressed.length is less than the cipher
block size, the MAC and padding data [1] will be used to construct the
first block.

The countermeasure:  instead of sending a completely empty fragment
before the supplied application data, send the first byte of
application data in a packet, followed by the remaining data from the
write call.  I think this should work because the TLS specification
requires content followed by the MAC.  Like the proposed solution,
you're still removing the adaptive guessing mechanism from the IV
calculation, but in a different way.

Assume here a cipher block size of 8.  Since the MAC effectively
randomizes the IV for successive SSL/TLS packets, if this first byte is
one of the bytes being guessed, that still leaves a search space of 28
(1 byte of data) * 256 (MAC) = 264, which is the same as the cipher
itself.  If the 1 byte is known plaintext, then the MAC will change the
IV for successive packets, and the attacker is not given the chance to
adapt the input Pj.

Implementations should readily accept 1 byte of application data, so
this will likely address the empty fragment issue, while complying with
the SSL 3.0 and TLS 1.0 specifications.

Looking forward to your comments.

Thanks,
Xuelei

[1] From a quick review of the standard hashes and ciphers of TLS
cipher suites, the CipherSpec.hash_size should be always bigger or
equal to block size. So the first block of an cipher operation should
not contain the padding data.