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 <[email protected]> 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 > // [email protected] > // "One if by land, two if by sea, three if by the Internet." > > On Nov 17, 2015, at 3:45 PM, Daniel Kahn Gillmor <[email protected]> > 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 > > >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
