Re: [TLS] Record header size?

[Eric Rescorla <[e-mail]>]

Can you expand on the alignment issues some more?

Thinking through how typical software stacks work, you first read
the record header into some buffer to figure out how long the record
is and then you read the record payload into a buffer, which may
not even be the same buffer. For instance, in NSS, there are
two buffers, one for the header and one for the body:

https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/ssl3gthr.c#53
https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/sslimpl.h#377

In a system like this, there's nothing stopping the body from being 4-byte
aligned, whatever the alignment of the header is. I'd be interested in
hearing
about the design you have in mind.

-Ekr








On Tue, Nov 17, 2015 at 12:59 PM, Short, Todd <[e-mail]> wrote:

> I would say that 32-bits would be optimal, since that is the typical
> word-size of processors that need alignment. 2-bytes isn’t much better than
> 5-bytes in this regard.
> --
> -Todd Short
> // [e-mail]
> // "One if by land, two if by sea, three if by the Internet."
>
> On Nov 17, 2015, at 3:45 PM, Daniel Kahn Gillmor <[e-mail]>
> wrote:
>
> On Tue 2015-11-17 12:09:30 -0500, Eric Rescorla wrote:
>
> 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.
>
>
> In particular, if we're going to make a change to the TLS record header,
> the change would be to remove the version and the type entirely, leaving
> only two octets of length on each record.  Is a two-octet offset going
> to be problematic?
>
>         --dkg
>
>
>