Re: [TLS] Record header size?

["Short, Todd" <[e-mail]>]

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
// [e-mail]<mailto:[e-mail]>
// "One if by land, two if by sea, three if by the Internet."

On Nov 19, 2015, at 4:38 AM, Martin Rex <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tls