Re: [TLS] Record header size?

[[e-mail] (Martin Rex)]

Yoav Nir wrote:
>> Peter Gutmann <[e-mail]> wrote:
>> 
>> Eric Rescorla <[e-mail]> writes:
>>> 
>>> The concern here is backward compatibility with inspection middleboxes which
>>> expect the length field to be in a particular place.
>> 
>> Given that the rest of TLS 1.3 is going to break compatibility with pretty
>> much everything everywhere, I can't see this as a big concern, may
>> as well fix it at the same time as everything else is being changed.
> 
> A sanity check on TLS might involve validating 5-byte record headers
> with sane length and version fields. A firewall might be out there that
> verifies this.

The issue is much more about breaking _applications_ on top of TLS
by changing the existing 5-byte record header.  Padding the header
to 8 bytes (3 bytes into the original record body) would be OK, though.

With several TLS implementations it is possible to completely seperate
network communication (of the application) from the processing of
TLS records (performed by the TLS protocol stack).  For some TLS
implementations (e.g. Microsoft SChannel) this seems to be the only
possible mode of operation.


When I changed our (middlware SSL) application APIs from blocking to
non-blocking communication semantics a few years ago, I also moved the
entire network communication out to the middleware above the TLS protocol
stack, and only _full_ TLS records will ever get passed to the TLS library.
Everything that doesn't have the regular TLS record header will be
unconditionally rejected by the middleware above the TLS implementation.
I also use the content type to distinguish application data records from
handshake records to properly manage the half-duplex TLS handshake and the
resulting application-facing progress reporting.

Any changes to the TLS record layer will push support for TLSv1.3 easily
a decade into the future.  Padding the TLS record header to 8 bytes should
be OK and fully backwards compatible with such code, because the actual
processing of the TLS record body happens inside the TLS implementation only.

As far as alignment is concerned, some of the crypto hardware support
(such as Intels AESNI) might need 16-byte alignment.  Intel CPUs have
load instructions to load 16-bytes aligned (MOVDQA) or unaligned (MOVDQU)
into or between XMMx registers, and the amount of extra clock cycles
depends on the severity of the "misalignment".

https://software.intel.com/en-us/articles/reducing-the-impact-of-misaligned-memory-accesses

https://software.intel.com/en-us/forums/watercooler-catchall/topic/304126


-Martin