Subject: Re: [rtcweb] Consensus call regarding media security

From: jesse <[email-masked]>
Date: Mon, 2 Apr 2012 16:34:46 -0700

On Mar 28, 2012 2:08 PM, "Basil Mohamed Gohar" <
[email-masked]> wrote:
>
> On 03/28/2012 04:41 PM, Roman Shpount wrote:
> > My main objection is that if an application developer does not take
> > care to develop a secure application, nothing you can do on the
> > standard side will make it a secure application. If I am building a
> > public voice blog that records a voice message that anybody can listen
> > to on the web site security is not needed. My assumption is that a
> > fair number of applications would be like this. So for such
> > applications this is an unnecessary feature.
> >
> > WebRTC will not exist in vacuum. It will communicate with other
> > systems. It is not limited to old SIP devices. It can be something new
> > like server side speech recognition that is integrated with web
> > application. For such application extra code and interop requirements
> > to support security will represent a real and significant cost. Any
> > requirement, unless absolutely necessary will create barriers to entry
> > for new applications. I would like to avoid as many of those as
> > possible.
> > _____________
> > Roman Shpount
> Roman,
>
> You make a lot of good points.  However, the inverse is true as well -
> namely, that is if encryption is not mandated, most implementations will
> likely leave it out,

That means SRTP unnecessary to fullfill major practical usage cases.

The decision to use telnet or ssh for remote desktop should be made by IT
department, not by standard committee.

- jesse

and adoption of secured communications would be
> stifled even longer.  I cannot speak about the implementation
> difficulties, but I can speak from the user side that most people will
> remain ignorant of the underlying technology and not know enough to
> demand nor enable a feature if it is optional to implement and/or use.
>
> As WebRTC is a new standard, requiring encryption will ensure that, at
> least going forward, the important concept of encryption is widely
> adopted correctly from the beginning.  Tacking it on later, no matter
> how much it is emphasized, will be difficult or impossible.
>
> The scope of WebRTC is broad enough to consider that we need to think
> about what's best going forward with regards to its implementation.
> Security by default is one of the best practices in general, the support
> from the browser community and others that are behind it will definitely
> ensure that adoption is widespread enough to make it easy enough to
> integrate into existing systems, as free software solutions will become
> available shortly after the standard emerges.
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 3 Apr 2012 01:45:42 +0200

The more than 500 millions of Facebook users are end users, not an IT
department.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 2 Apr 2012 20:44:01 -0400

> The more than 500 millions of Facebook users are end users, not an IT

If Facebook does not want to provide security to its users, standards
committee will not make it secure.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 2 Apr 2012 20:53:03 -0400

On Wed, Mar 28, 2012 at 5:08 PM, Basil Mohamed Gohar <
[email-masked]> wrote:

> likely leave it out, and adoption of secured communications would be
If application developer does not care about security nothing we do will
force the application to be secure. For instance, if SDES-SRTP is allowed,
I can implement something that will communicate with it with less then 1000
lines of code. I will drop the replay protection, real random key
generation and will just leave AES-CM and check sum calculation. This will
still successfully communicate with WebRTC end points but will not be
secure by a long stretch. We can provide the tools to secure the
communications, but unless application is properly developed, it will only
go through the motions of encryption without achieving any real results.
So, as a result, allowing non-encrypted communications will actually result
in more secure ecosystem. Where people who need security will support it,
and people who do not need security will clearly show that secure
communications are not implemented by their application.
_____________
Roman Shpount

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 03 Apr 2012 12:10:30 +0200

Changing the subject, since this message is not a position on the 
consensus call.

On 03/29/2012 07:31 PM, Fabio Pietrosanti (naif) wrote:
> On 3/29/12 7:02 PM, Ravindran, Parthasarathi wrote:
>> WebRTC trust model has to be considered as one of the main factor for deciding the key mechanism. AFAIK, SDES does not fit into WebRTC as Dr.Evil HTTPS RTCWeb server must be trusted in case of SDES. There is no means to track or analyze whether Dr.Evil involves in monitoring or recording or terminate the media traffic.  It will be good in case whoever advocate for SDES explain how SDES fits within WebRTC trust model.
> Sure!
>
> From:
> http://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/?include_text=1
>
> "   The basic assumption of this architecture is that network resources
>     exist in a hierarchy of trust, rooted in the browser, which serves as
>     the user's TRUSTED COMPUTING BASE (TCB).  Any security property which
>     the user wishes to have enforced must be ultimately guaranteed by the
>     browser (or transitively by some property the browser verifies)."
>
> So, it means that if the browser already have a hierarchy of trust to
> use TLS for HTTPS, then SDES-SRTP will inherit the trust-properties of
> the HTTPS website from which it's loaded.
Ahem.... SDES-SRTP will "inherit" the property that as long as the HTTPS 
trust chain is intact, only attacks where the HTTPS website, or entities 
that the HTTPS website chooses to reveal the key to (voluntarily or 
involuntarily) can listen in on the call.

(The plenary at the IETF made interesting background for this claim.)
> It seems to me quite easy to fit SDES-SRTP into the browser model, as it
> allow you to assure that the communication path between the client and
> the server is secure.
>
> Do you expect WebRTC to be only peer-to-peer/client-to-client?
>
> I sincerly expect *a lot* of communications to goes trough SIP/RTP media
> proxy for security purpose, for billing purposes, for value added
> service purpose.
In the cases where a gateway needs to decrypt the packets, the gateway 
is the logical peer with the browser in the (DTLS-)SRTP trust relationship.
> SDES-SRTP provide a very reliable and simple way to let a WebRTC peer to
> establish security with the server, assuming that it already have
> established security trough HTTPS/TLS that's a consolidate trust method.
The term "the server" is a fallacy. The Web server and the media gateway 
(if there is one) are likely not the same server, and may even be 
operated by different entities.
SDES-SRTP forces you to trust both.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 3 Apr 2012 13:55:38 +0200

2012/4/3 Harald Alvestrand <[email-masked]>:
> The term "the server" is a fallacy. The Web server and the media gateway (if
> there is one) are likely not the same server, and may even be operated by
> different entities.

If you trust the Web server (i.e. due to HTTPS usage with a valid
server certificate) then you will also trust that the Web server will
not signal your WebRTC communication to a malicious destination, am I
wrong?

Don't take me wrong but, which kind of security obsession are we
trying to satisfy in rtcweb? a media communication is not more
important than a web access to my back website in which I enter my
credit card PIN. Does IETF define "security standards" for POS ("Point
of sale terminal") for making a bank payment via a 3rd web
(e-commerce)? AFAIK not.

If the Web server (assuming HTTPS) is trusted and SDES-SRTP used, we
should trust the communication. If it fails that is because the Web
server has been attacked. If that occurs, it's really worse the case
in which my bank website has been attacked (I'm giving my credit card
PIN to the attacker).

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 3 Apr 2012 13:56:50 +0200

2012/4/3 Iñaki Baz Castillo <[email-masked]>:
> important than a web access to my back website

typo: I meant "bank website"

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Randell Jesup <[email-masked]>
Date: Tue, 03 Apr 2012 08:31:50 -0400

On 4/3/2012 7:55 AM, Iñaki Baz Castillo wrote:
> 2012/4/3 Harald Alvestrand<[email-masked]>:

Partly.  First, as you mention, the site can be hacked.  Another issue 
is that you may NOT trust the website to avoid tapping your 
communication (and in fact they may be legally obligated to do so, and 
have no choice in the matter).  Also, as shown by Diginotar, website 
certs can be forged transparently if a CA is hacked.  Those are both 
real-world cases where you cannot trust the site you connect to via 
https to secure your data (in addition to "the site was hacked", even if 
they are "trustworthy".

> of sale terminal") for making a bank payment via a 3rd web

No, but other organizations define such standards in great detail - and 
still there are weekly breaches of security that require credit card 
companies to send out thousands or millions of replace cards & numbers.

And a site providing media communication will not have the ultra-strict 
security reviews and audits that come with processing credit card info, 
and so is much more likely to be hacked.

> in which my bank website has been attacked (I'm giving my credit card

It can be far worse - most people are given guarantees about how much 
they can lose (often $0) - a hassle is all usually; sometimes a big 
hassle, but not harmful personally.  Media interception (especially 
video) can cause horrible repercussions in some cases - blackmail, 
embarrassment, scandal, and in countries like Iran or cases like the 
Arab Spring, jail or death.

-- 
Randell Jesup
[email-masked]

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 3 Apr 2012 16:23:50 +0200

2012/4/3 Randell Jesup <[email-masked]>:
> Partly.  First, as you mention, the site can be hacked.

If the site is hacked then it does not matter whether SDES or DTLS is
being used. Both can be hacked as demostrated in some draft (whose
name cannot remember now).

> Another issue is that you may NOT trust the website to avoid tapping your communication

The communication is not just the RTP, but also the signaling. If my
wife (if I had) realizes that yesterday night I called to my
ex-girlfriend, that's important enough for me (regardless my wife does
not know what I talked with her). So what? no servers? no proxies?
pure P2P for all?

Also, as said in other mail (by other person in this maillist), if you
don't trust the web server, then we must also drop TURN from WebRTC
since TURN URI's are provided by the web server (and it can be hacked
and so...).

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 Apr 2012 10:36:59 +0200

WG, EKR

The deadline for this call of consensus has ended. I note that there has
been discussion of a number of details and additional views on the
actual consensus statement made. Some supporting the consensus from the
meeting room and some opposing it. In the end I determine that the two
consensus statements are confirmed:

 The first was that there was overwhelming consensus that all RTP
 packets SHALL be protected by SRTP.

 Secondly that no one objected against making DTLS-SRTP a mandatory to
 implement and the default keying mechanism. Additional mechanisms are
 not precluded.

>From the discussion in the thread I would note the following:

1) Null cipher for encryption is strongly desired but an actual proposal
is needed for how to express this.

2) Details of the SRTP and DTLS-SRTP usage in this WG needs to be
defined. This is for continued discussion. I hope our editor of the
security architecture can make a proposal to the WG to consider.

3) The discussion of additional keying mechanisms such as Security
Descriptions and Encrypted Key Transport will continue.

Cheers

Magnus

On 2012-03-28 16:50, Magnus Westerlund wrote:
> WG,
> 
> In todays RTCWEB WG meeting there was discussion around media security
> mechanism. In this meeting there was some clear consensus in the
> meeting which we would like to confirm on the list.
> 
> The first was that there was overwhelming consensus that all RTP
> packets SHALL be protected by SRTP.
> 
> Secondly that no one objected against making DTLS-SRTP a mandatory to
> implement and the default keying mechanism. Additional mechanisms are
> not precluded.
> 
> WG participants may state their position regarding these consensus calls
> until 12th of April when the chairs will declare the final consensus. If
> you where present in the meeting room and comment on this, please
> indicate that.
> 
> Best Regards
> 
> Magnus Westerlund
> For the WG chairs
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Apr 2012 07:57:44 -0400

> security architecture can make a proposal to the WG to consider.

Acknowledged.

I will do so.

-Ekr