Re: [TLS] Record header size?

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 <tshort@akamai.com> 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
> // tshort@akamai.com
> // "One if by land, two if by sea, three if by the Internet."
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>