Re: Requiring a secure transport layer for Intents and similar things (DAP standards best practices?)

OK, Josh informed me that this email is the result of an AI to write
up his thoughts on the subject.

Proponents of requiring a secure transport layer: do you have any
insights on my questions below?

Thanks,
James

On Tue, Sep 4, 2012 at 8:09 AM, James Hawkins <jhawkins@google.com> wrote:
> I remember we talked a bit about this at the last F2F, but I don't
> remember what decision we made wrt secure transport (if we made one at
> all).
>
> I'm slightly concerned that requiring SSL/TLS will present a barrier
> to adoption on developers.  Is there precedence on the web platform
> for requiring secure transport?
>
> Josh, is your proposal to require a secure transport layer on the
> client side, server side, both?
>
> Thanks,
> James
>
> On Tue, Aug 28, 2012 at 1:26 PM, Josh Soref <jsoref@rim.com> wrote:
>> Analogies.
>>
>> #1 hardware peripherals
>> When a user buys a peripheral (keyboard, mouse, scanner), they are able to physically inspect it to determine at the time of purchase what it will do. They can install it, and again they can inspect it to determine what it will do. They can also rely on the reputation of the vendor. After purchase, if the vendor's reputation is sullied, they can recognize the vendor's name in the news, identify that the peripheral they have is from that vendor and take an action.
>>
>> Take the case of a keyboard. If someone decides to install a physical pass through keylogger between the keyboard and the computer, then the owner of the keyboard/computer is theoretically in a position to physically see that the keylogger exists. In most cases, I believe that the OS will also be able to inform the user of the USB connection (although I'm less certain about this), certainly if it's a basic hub instead of some very evil system.
>>
>> It doesn't matter where in the world the user takes this hardware.
>>
>> Essentially, with hardware, what you get at time of purchase is what you have, and thus you only need to inspect it once.
>>
>> #2 locally installed software.
>> When a user buys software that installs locally onto an OS outside of a runtime, the user can rely on a one time virusscan (or uploading the files to some system which continuously scans) of the installed snapshot to determine the security of the software. Modern software for Windows (and OS X, and Linux) is signed - Windows uses Authenticode, Linux tends to use PGP/GPG.
>>
>> It doesn't matter where in the world the user takes this installed software.
>>
>> Each time the user runs the software, the software that is run is the same as the software that was run the previous time, and the signature / checksum from the original install is sufficient for the user to trust the software.
>>
>> #3 web sites served over SSL/TLS
>> When a user visits a service served via https, the browser (IE9+) will not load insecure content, and will not load the site/content if the certificate for the session isn't trusted. This is /slightly/ different from the previous two instances, but mostly the user is able to make a one off determination "I trust <certificate list + site>". Reputationally, if the service does something silly and steals data, the user will be able to read about it in the newspaper and recognize they're affected (as with #1/#2).
>>
>> It doesn't matter where in the world the user is - caveat as long as they're using hardware they trust (this caveat applies to #1/#2).
>>
>> #4 web sites served over HTTP
>> If you visit a site that's served over http, you could be talking to the site you think you're talking to, and it could be that today no one is eavesdropping on your communications. However, that knowledge isn't portable to your next visit to the same server. And it certainly isn't portable if you take your computer to another ISP/AP, especially a Net Café. This is significantly different from #1/#2/#3. There's no way for the user, or the system, or anything else to recognize/indicate that there's a problem. And the problem could be for a single session. This isn't the way normal hardware/software behaves and is incredibly surprising. When the user take their laptop to the Net Café, the user expects the laptop itself to operate the same way as it did when it was elsewhere, it shouldn't magically leak information, it shouldn't magically become infected. Sure, if the user happens to go to a site that says it's http, the user can see that the site isn't https and understand that the information entered may be insecure, but the user has no reason to think that the browser/OS are suddenly insecure. And if the user goes to an https site, the user reasonably assumes that traffic involving that site is secure (up to the reputation of that site).
>>
>> If the user installs an Intent at home and the Intent happens to be served via HTTP, and the user visits a Net Café and triggers the intent, the user isn't going to be warned in any useful way (and 99% of the time we could warn it'd be a spurious warning - because most APs aren't evil, which makes it a bad warning) that their information is being leaked. The only way to make Intents safe is to not offer this option at all. Otherwise, people will serve intents via http, 99.9% of the time it'll be ok, but users will have information stolen from them, or evil software interposed in place of the software they expect to be running. Users know that when they take a mouse/keyboard with them to a Net Café, it doesn't magically get replaced when they walk in the door.
>>
>> Anyway, that's the problem space...
>> Sorry for the delay.
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>

Received on Tuesday, 4 September 2012 22:10:16 UTC