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

[Juho Vähä-Herttua <[e-mail]>]

14.6.2010 10:46, Nikos Mavrogiannopoulos kirjoitti:
> I don't understand your point. Implementations that want to support
> could support it (i.e. when implementing for a high bandwidth tunnel),
> and others can use the 16kb limit. Being able not to use it is an
> advantage not a limitation.
>    

Of course, and I also find it strange that 2^13 is left out from the 
specification, since it's less than 2^14. I'm mainly questioning if 
raising it to 2^15 is much help (it's just 16kB vs 32kB there). In 
practice you can't raise it to 2^16 because of the IV, padding and MACs, 
and defining numbers between 2^15 and 2^16 feels a bit ugly as well and 
might require fixing later if there's more additional payload defined 
that wasn't known during the specification. All implementations can work 
around these naturally, but from specification point of view things that 
might have to be removed later shouldn't be added. Maybe adding 32kB and 
48kB would be a nice middle ground, but it would be nice to have some 
proof of the benefits and performance improvement.

> Then it shouldn't negotiate it. Isn't it obvious? The extension is for
> applications that require more bandwidth and are not running on 8 or
> 16 bit cpus. This is an extension you use it when you need it, not
> when you don't.
>    

Well, the extension specification itself says it's for applications that 
have memory and bandwidth limitations. With the modification of 
accepting values larger than 2^14 it could be modified to also work on 
applications that require more bandwidth, which is your point I guess.

> 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. After that the benefits of having 
a larger record fragment length can be discussed, since these ciphers 
are probably the ones benefiting from it the most. The authenticating 
ciphers might be hard to get into mainstream use before the stable 
versions of free software implementations catch up and start to support 
them as well, though.


Juho