Re: [TLS] Record header size?

[[e-mail] (Martin Rex)]

Viktor Dukhovni wrote:
> On Thu, Nov 19, 2015 at 12:05:55PM +1000, Michael Gray wrote:
> 
> > > With several TLS implementations it is possible to completely seperate
> > > network communication (of the application) from the processing of
> > > TLS records (performed by the TLS protocol stack).  For some TLS
> > > implementations (e.g. Microsoft SChannel) this seems to be the only
> > > possible mode of operation.
> > 
> > We have the same kind of IO separation and I have observed a few times that
> > some products either interleave/multiplex TLS records with other
> > application data flow or route/buffer TLS traffic based on TLS record
> > header checking.  Padding the header to 8 bytes, as above, would probably
> > be OK.
> 
> Before we seriously consider going there, we should make sure that
> this really addresses the problems that the hardware vendors
> reputedly have.
> 
> Is it enough to pad just the application-data records (effectively
> prepend 3-nul bytes to every application data record, and think of
> it as either a longer record header, or initial data padding)?  Or
> do the vendors in question need alignment of the handshake packets
> too?  My guess is that changing the alignment of the handshake
> packets would not be as useful, and would reduce interoperability
> (confuse more middle-boxes).  But this guess could be wrong.
> 
> Can anyone definitively confirm the actual requirements?


The padding issue was about inplace or hardware-based encryption/decryption
and would depends on whether the TLS record payload is encrypted (ciphertext)
or not (cleartext) -- the content type (handshake or app data) is irrelevant.
There is no need to pad cleartext TLS records (aka initial handshake
messages).

-Martin