Re: [TLS] I-D Action:draft-ietf-tls-rfc4366-bis-09.txt

[Nikos Mavrogiannopoulos <[e-mail]>]

On Mon, Jun 14, 2010 at 10:23 AM, Juho Vähä-Herttua <[e-mail]> wrote:

>> The save is not on data sent but on processing speed. Decryption and
>> encryption today is done in hardware (several embedded systems have a
>> crypto coprocessor) so the bottleneck is on processing those
>> fragments. The larger they are the less they are processed, the higher
>> the bandwidth. (check what happens to ATM today with the fixed 53 byte
>> payload, everybody tries to do reassembly in hardware otherwise the
>> performance is poor. 16kb is not 53 bytes but it's close :)
>>
>
> I don't deny this, larger chunks of data are always easier to process,
> especially if the process can be done in parallel. One of the biggest
> bottlenecks in TLS decryption performance I can see, is the stream and CBC
> block ciphers requiring decryption before the MAC calculation can be
> initiated. Therefore, if the decryption and encryption performance is really
> important, I'd rather concentrate on getting the AES-GCM and AES-CCM ciphers
> into wider use in TLS.

This is orthogonal to what I proposed. What I say provides advantage
irrespective to the ciphersuite used. And in reality the faster the
ciphersuite is, the more the need for larger payloads, that is because
the bottleneck now becomes processing and not encryption.

regards,
Nikos