Yoav Nir wrote: >> Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote: >> >> Eric Rescorla <e...@rtfm.com> 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
