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]<mailto:[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
