Yes, this has to do with encrypted records. The non-encrypted handshake records are already hard enough to parse that the 5-byte header doesn’t mean much. I have worked on designs where the general-purpose processor handled the handshake and non-encrypted records, and a crypto co-processor handled the encryption. -- -Todd Short // tsh...@akamai.com<mailto:tsh...@akamai.com> // "One if by land, two if by sea, three if by the Internet."
On Nov 19, 2015, at 4:38 AM, Martin Rex <m...@sap.com<mailto:m...@sap.com>> wrote: 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<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
