The concern here is backward compatibility with inspection middleboxes which expect the length field to be in a particular place. We agreed in Seattle to wait for early deployment experience before modifying the header to move the length.
-Ekr On Tue, Nov 17, 2015 at 7:25 AM, Short, Todd <[email protected]> wrote: > Apologies if this has been brought up before. > > Has there been any consideration to changing the record header for > encrypted traffic to be 4 bytes (i.e. 32-bits)? 5 bytes is a very awkward > size, and some processors do not handle odd byte offsets well (it was a > complaint I heard from Cisco router/switch engineers). > > The latest TLS1.3 draft indicates that the record_version is deprecated > and must be ignored. If TLSv1.3 is negotiated, then I propose that the > record_version value must be { 4 } for encrypted records, making the > version field is a single byte, such that the length of the record_header > is reduced to 4 bytes. > > Alternatively, a TLS extension could be added to negotiate the size of the > record_header. > > Yes, this creates a serious backwards compatibility issue, but if the > record_version field is deprecated, then perhaps a change to the > record_header could be made. > > Thus: > > struct { > uint8 major; > uint8 minor; > } ProtocolVersion; > > struct { > ContentType type; > ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */ > uint16 length; > opaque fragment[TLSPlaintext.length]; > } TLSPlaintext; > > struct { > ContentType opaque_type = application_data(23); /* see > fragment.type */ > uint8 record_version = { 4 }; /* TLS v1.3 4-byte record header */ > uint16 length; > aead-ciphered struct { > opaque content[TLSPlaintext.length]; > ContentType type; > uint8 zeros[length_of_padding]; > } fragment; > } TLSCiphertext; > > -- > -Todd Short > // [email protected] > // "One if by land, two if by sea, three if by the Internet." > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
