Re: [rtcweb] Let's define the purpose of WebRTC

[Eric Rescorla <[e-mail]>]

On Thu, Nov 10, 2011 at 1:07 PM, Hadriel Kaplan <[e-mail]> wrote:
>
> On Nov 10, 2011, at 12:20 AM, Eric Rescorla wrote:
>
>> I can envision situations on which security would be desirable in both of
>> these applications. In the case of a "greeting card application" (whatever
>> that is) my greeting card might contain sensitive personal or medical
>> information (congratulations on your pregnancy, sorry to hear you have
>> cancer etc.) Surely I do in fact want that information secured. Similarly,
>> it might not be important to have my Farmville chats secure, but if the
>> purpose of an in-game chat is for me and my co-player to cooperate
>> in a game where money is on the line (e.g., a tournament), then suddenlu
>> security becomesmuch more important. Not to mention that the players
>> may simply be using in-game chat to discuss personal stuff.
>
> I think that's a red herring.  Just because you as a user could post your social security number on a forum website, for example, does not mean all forum websites should use HTTPS "just in case".  Because even if they used HTTPS it's not going to secure your social security number from being read by anyone else, nor does the forum website claim to provide any such form of confidentiality to begin with.

This isn't my point: Roman offered a set of use cases he claimed didn't
require confidentiality. But in fact, many such cases do. The fact that
there are also overlapping cases which do not is an argument for erring
on the side of confidentiality, not the other way around.


> The greeting card case, for example, is going to record your media on some server somewhere - just because they use SRTP from you to do so doesn't mean they're going to prevent everyone on the planet from being able to access the greeting card; or even if they only allow authorized users to listen to the greeting card, it doesn't mean that they won't simply use an HTTP'ed wav file to deliver it to them.  Obviously if a greeting card app *wants* to provide that sort of confidentiality/privacy, then it can and should use SRTP as well as encrypt everything else, control authorization, etc.  That's their choice, based on what type of application they want to provide.

Would that this were in fact true. But I don't think history supports
this argument.
Quite the contrary: we have a whole array of protocols which really should
be secure all the time (e-mail is a good example) but aren't because they
were initially deployed insecure and it's hard to convert. The good
news, however,
is that WebRTC can be done securely from the beginning in a way that
(unlike HTTPS) doesn't impose significant inconvenience on the site operator.


>> The point is that it's very hard to anticipate which communications media
>> will be used for sensitive information. To say "we don't need security
>> in this application because nobody will ever use it to discuss sensitive
>> stuff" is short-sighted. Better simply to be secure all the time.
>
>
> And one could argue this the exact opposite - if the browser shows some lock-icon thing for SRTP, then it's better for them to use RTP instead for such apps, so as not to make you think the service as a whole is secure if it really isn't.

Obviously, UI confusion is a real problem, but I don't really buy the
argument that
Facebook shouldn't use HTTPS because people will be confused about what
happens when they post on their wall.

-Ekr