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