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?
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
