Re: I revised the pro/contra document

Mike,

> On Nov 23, 2013, at 8:12 PM, Mike Belshe <mike@belshe.com> wrote:
> 
>> On Sat, Nov 23, 2013 at 4:01 PM, Michael Sweet <msweet@apple.com> wrote:
>> Alexandre,
>> 
>> There is a processing overhead associated with encryption - I've seen up to a 40% speed penalty for printers, for example. When applied to streaming of large files like movies (which already have their own layer of protections), that generally means the provider needs more servers with hardware accelerated TLS, and similarly more processing needs to be done on each client which may limit the quality/quantity of video that can be played. And imagine the increased power usage - not the direction most people are trying to go...
> 
> Do you have any benchmarks on this?  Or a breakdown of printers print that slowly?  Are these modern printers or old ones? 

Brand new consumer/SOHO printers. The impact is less on enterprise office equipment, and there are some mid-range printers with PDF support that, while they don't do TLS any faster they have less data to move. I am actually working on a white paper to summarize the results.

> If a typical printer is printing 10ppm, we need to keep the flow of a page of data per 6 seconds.  In 6 seconds, you can do a lot of computing and transmit a boatload of bits, even on a modest printer.

Consider that you are pumping 100MB of raster data per page for a typical consumer/SOHO printer. With compression you can get that down to about 1/5th of that on average (better for text, worse for photos). So figure 3.4MB/sec.

Most printers in this class use microcontroller/SoC implementations that are hard pressed to maintain that data rate. Add a software TLS implementation and they just don't keep up.

>  I know that printers use small and sometimes memory constrained CPUs, but given the slowness of actually printing a page, I have a hard time believing that TLS can't keep up most of the time.  I also wouldn't be surprised if the failure here was implementation quality rather than TLS itself.  

There is an overhead in TLS, even for "good" implementations. It doesn't come for free.

> So before we throw TLS under the bus for all of the internet in order to save what may be a tiny segment of printers (that can still use HTTP/1.1 if they want to!), I think we should quantify this problem with real data.
> 
> For what it is worth, despite my skepticism about the 40% number, I'd still rather prefer safe data transmission and a 40% print speed loss than have my data stolen by the guy sitting next to me at kinko's.

And clearly printing at kinkos is different than printing at home or printing in an office.

Today you'll find many printers that support TLS but none that enable it out of the box. Most have a button or menu item to turn it on, which generates a self signed certificate. And most also allow you to upload "real" certs. You, as the customer/user/owner get to decide whether to use it or not...

> 
> Mike
> 
> 
> 
> 
> 
>  
>> 
>> Aside from the basic resource issues, consider printing again. Most printers are not used in environments that need encryption. Those that do often do not have stable addresses or host names, making authentication and certificate management a greater challenge. So for printers I have personally fought hard for all TLS support but not necessarily to enable it by default.
>> 
>> Sent from my iPad
>> 
>> > On Nov 23, 2013, at 4:27 PM, Alexandre Anzala-Yamajako <anzalaya@gmail.com> wrote:
>> >
>> > I am sorry if these points were discussed before but i don't get why tls isn't appropriate for media files or why we shouldn't secure our connections to printers ?
>> >
>> > Cheers
>