Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Fri, 16 Mar 2012 19:25:46 +0000

Magnus,

As I mentioned in earlier mail thread (http://www.ietf.org/mail-archive/web/rtcweb/current/msg03148.html), RTP has to be supported by RTCWeb client with local user consent.

To clarify why RTP is not harmful in some usage, VPN access of intranet RTCWeb client in public internet usecase is as follows: 

Usecase details: Enterprise employee Alice access enterprise (HTTP & WebRTC compliant) intranet with VPN connection using Airport WiFi internet connection, Alice will have the mechanism to call another employee Bob in the same enterprise using WebRTC session and the session between Alice and bob will be plain RTP in VPN network.

Security aspect: Here, accessing (HTTP) intranet browsing today is safe even though Alice is using Airport Wifi internet connection as he has VPN connection (IPSec) and no dependency on HTTPS. In the same way, WebRTC mechanism should not mandate for SRTP-DTLS in media and MUST allow RTP.  The local user consent (configuration) is required to restrict this usage by Dr Evil website.

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Magnus Westerlund
>Sent: Friday, February 24, 2012 3:05 PM
>To: [email-masked]
>Subject: [rtcweb] Resolving RTP/SDES question in Paris
>
>WG,
>
>There has been extensive discussion at WG meetings at whether we need to
>support SDES and RTP in addition to DTLS-SRTP. The architecture draft
>currently has a giant "Open Issue" text around the question of the
>appropriate level of support for modes less secure that DTLS-SRTP.
>The draft currently implicitly allows but does not require these modes:
>
>  Implementations MUST implement DTLS and DTLS-SRTP.  All data channels
>  MUST be secured via DTLS.  DTLS-SRTP MUST be offered for every media
>  channel and MUST be the default; i.e., if an implementation receives
>  an offer for DTLS-SRTP and SDES and/or plain RTP, DTLS-SRTP MUST be
>  selected.
>
>The chairs intend to use significant meeting time in Paris with an aim
>to reach consensus around this issue. Please consider this thread an
>invitation to discuss this topic on the list. In Paris, we intend to
>have a presentation summarizing the discussion so far, digging into the
>details of different possible outcomes and of the arguments have been
>raised in order to set the stage for a discussion and a consensus call.
>
>Please come prepared to have that discussion in Paris.
>
>Magnus Westerlund
>(For the WG chairs)
>
>----------------------------------------------------------------------
>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]
>----------------------------------------------------------------------
>
>_______________________________________________
>rtcweb mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Randell Jesup <[email-masked]>
Date: Fri, 16 Mar 2012 18:10:22 -0400

> As I mentioned in earlier mail thread (http://www.ietf.org/mail-archive/web/rtcweb/current/msg03148.html), RTP has to be supported by RTCWeb client with local user consent.

That is your stipulation.  Thus far this does not have consensus.

> Usecase details: Enterprise employee Alice access enterprise (HTTP&  WebRTC compliant) intranet with VPN connection using Airport WiFi internet connection, Alice will have the mechanism to call another employee Bob in the same enterprise using WebRTC session and the session between Alice and bob will be plain RTP in VPN network.
>

This says the media is in theory 'safe' as RTP over a VPN.  Similar 
arguments were used for "inside the corporate network" in previous 
discussions.  That doesn't mean that the spec should allow for RTP; for 
example it might create bid-down attack possibilities - and the 
application has lots of trouble knowing if hte link really is secure 
(and doesn't transition off security anywhere after leaving the machine).

-- 
Randell Jesup
[email-masked]

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 16 Mar 2012 23:55:00 +0100

> As I mentioned in earlier mail thread (http://www.ietf.org/mail-archive/web/rtcweb/current/msg03148.html), RTP has to be supported by RTCWeb client with local user consent.

Well, that's your opinnion, not a MUST (or not yet).

> Security aspect: Here, accessing (HTTP) intranet browsing today is safe even though Alice is using Airport Wifi internet connection as he has VPN connection (IPSec) and no dependency on HTTPS. In t…

To clarify why RTP *is* harmful in *common* usages:

Usecase details: An user in an airport using an open WiFi connection
and accesing to a social web page implementing WebRTC for calls
between web users and between web users and PSTN numbers. And not, the
user does not use a VPN to connect to a social web. The user calls to
a PSTN number (since the contact he wants to call to is not currently
online in the web). The call is established with a SIP PSTN gateway
which does not implement SRTP but just RTP.

Security aspect: Plain RTP is negotiated so anyone in the airport can
spoof the media. A good reason to state "WebRTC mechanism MUST mandate
for SRTP and MUST NOT allow plain RTP, since the security aspect
depends on the service provider (and there are tons of irresponsible
service providers out there in Internet).

> The local user consent (configuration) is required to restrict this usage by Dr Evil website.

Giving the security responsability to end users as a configurable
option is not a good idea. The world would be much better if the
browsers would not allow plain HTTP, but it's not possible to change
the WWW requeriments and mandate HTTPS given the ammount of plain HTTP
deployments. In contrast, WebRTC does not exist yet so *now* is the
moment to mandate security.

Regards.

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

---

From: Roman Shpount <[email-masked]>
Date: Fri, 16 Mar 2012 19:35:08 -0400

> moment to mandate security.
And you imply that the fact that security is most of the times unnecessary
and often prohibited, has absolutely nothing to do with using HTTP over
HTTPS. If you think people in the military or in prisons do not use web
browsers, think again. Requiring secure communications will prevent them
from using WebRTC.

Furthermore comparison between HTTP/HTTPS and RTP/SRTP in not entirely
appropriate. HTTPS communications are reasonably secure. SRTP calls, unless
we make identity management a requirement for WebRTC, are only giving
people a false sense of security. The fact that browser uses SRTP does not,
in any way, imply that the communication is secure. If the key was
delivered over HTTP, anybody intercepting your IP traffic can listen to it.
If we are dealing with the server based attack then all hell breaks loose.
So, unless we requiring that only connections are over DTLS-SRTP using an
SDP signed by a verified remote party are allowed, we allow unsecure
connections. We need to show an appropriate warning for all of them, and
warning RTP vs SDES-SRTP vs unsigned DTLS-SRTP should not be very
different. It should say "You are trying to communicate over unsecure
peer--to-peer channel with an unknown party. Continue?" There is no, "you
are trying to use slightly more secure channel. Is this ok?".
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 Mar 2012 20:58:17 -0700

> browsers, think again. Requiring secure communications will prevent them

This doesn't seem obvious at all. Rather it will require the people who wish
to access their communications to do so explicitly in the same way as
enterprises who wish to monitor HTTPS do so now.

-Ekr

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Sat, 17 Mar 2012 04:13:31 +0000

Randell,

In my usecase, the application will not be able to access the website without VPN connection . Please explain your bid-down attack in my usecase. 

You can speculate that all intranet in the world shall be broken in a moment if they use HTTP but IMO, it is just speculation. IETF specification has to be generic enough to serve all the deployment rather than handling some specific mechanism or application only.

Thanks
Partha
>Of Randell Jesup
>Sent: Saturday, March 17, 2012 3:40 AM
>To: [email-masked]
>Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris
>
>> As I mentioned in earlier mail thread (http://www.ietf.org/mail-
>archive/web/rtcweb/current/msg03148.html), RTP has to be supported by
>RTCWeb client with local user consent.
>
>> To clarify why RTP is not harmful in some usage, VPN access of
>intranet RTCWeb client in public internet usecase is as follows:
>>
>> Usecase details: Enterprise employee Alice access enterprise (HTTP&
>WebRTC compliant) intranet with VPN connection using Airport WiFi
>internet connection, Alice will have the mechanism to call another
>employee Bob in the same enterprise using WebRTC session and the session
>between Alice and bob will be plain RTP in VPN network.
>>
>> Security aspect: Here, accessing (HTTP) intranet browsing today is
>safe even though Alice is using Airport Wifi internet connection as he
>has VPN connection (IPSec) and no dependency on HTTPS. In the same way,
>WebRTC mechanism should not mandate for SRTP-DTLS in media and MUST
>allow RTP.  The local user consent (configuration) is required to
>restrict this usage by Dr Evil website.
>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Sat, 17 Mar 2012 04:31:46 +0000

Ekr,

As Roman mentioned for specific military & prison deployment, some of the Enterprise will also restrict public internet HTTPS usage as it may risk Enterprise business.

Thanks
Partha

>Of Eric Rescorla
>Sent: Saturday, March 17, 2012 9:28 AM
>To: Roman Shpount
>Cc: [email-masked]
>>> the WWW requeriments and mandate HTTPS given the ammount of plain
>>> HTTP deployments. In contrast, WebRTC does not exist yet so *now* is
>>> the moment to mandate security.
>>>
>>
>> And you imply that the fact that security is most of the times
>> unnecessary and often prohibited, has absolutely nothing to do with
>> using HTTP over HTTPS. If you think people in the military or in
>> prisons do not use web browsers, think again. Requiring secure
>> communications will prevent them from using WebRTC.
>
>This doesn't seem obvious at all. Rather it will require the people who
>wish to access their communications to do so explicitly in the same way
>as enterprises who wish to monitor HTTPS do so now.
>
>-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 Mar 2012 22:06:55 -0700

> As Roman mentioned for specific military & prison deployment, some of the Enterprise will also restrict public internet HTTPS usage as it may risk Enterprise business.

Generally the way this is done is by deploying MITM proxies.

-Ekr

---

From: Randell Jesup <[email-masked]>
Date: Sat, 17 Mar 2012 02:05:20 -0400

> In my usecase, the application will not be able to access the website without VPN connection . Please explain your bid-down attack in my usecase.

It may not in your particular case.  But the application would have to 
know the connection was over VPN and somehow verify that (how?)  Careful 
about saying "the server can't be accessed unless the VPN is up" because 
traffic can be spoofed (and not just DNS traffic) if the attacker 
controls the first router/etc.

The solution has to be solid without the user having to verify things 
and such that there isn't a high likelihood of minor mistakes 
compromising the user's security.

> You can speculate that all intranet in the world shall be broken in a moment if they use HTTP but IMO, it is just speculation. IETF specification has to be generic enough to serve all the deploymen…

Well, no, IETF specs do not have to serve "all" deployments or 
applications.  That's why we try to agree to use-cases and have goals.  
Often trying to solve *all* variations or cases leads to a 
never-finished, too-complex design.  It can at times be better to focus 
on a few related or similar cases that we know there's a need for, and 
later specs can extend it or provide alternatives.

Of course, we try to include as wide a range of uses as possible, and so 
your use-case may be included, but I don't think we included it in our 
use-case document last fall.

-- 
Randell Jesup
[email-masked]

---

From: Tim Panton <[email-masked]>
Date: Sat, 17 Mar 2012 11:52:43 +0000

> In my usecase, the application will not be able to access the website without VPN connection . Please explain your bid-down attack in my usecase. 

I think there probably is an vulnerability if Bob goes on line (to upgrade the call to video say) and happens to be on the
same wifi ISP as Alice. The ICE probes may find a route between them that does not involve Alice's corporate VPN, but rather
over the non-routable ISP's /16 network. This would result in RTP in the clear being visible on both parties local wifi.

It's a slightly contrived case, but not impossible. 

Tim.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 17 Mar 2012 17:24:16 +0100

2012/3/17 Roman Shpount <[email-masked]>:
> we make identity management a requirement for WebRTC, are only giving people
> a false sense of security. The fact that browser uses SRTP does not, in any
> way, imply that the communication is secure. If the key was delivered over
> HTTP, anybody intercepting your IP traffic can listen to it. If we are
> dealing with the server based attack then all hell breaks loose. So, unless
> we requiring that only connections are over DTLS-SRTP using an SDP signed by
> a verified remote party are allowed, we allow unsecure connections.

Well, I just said that in order to get secure communications WebRTC
has to mandate SRTP and disallow plain RTP. I didn't enter in details
but of course I agree with you. However to accomplish with your
points, my statements (SRTP is a MUST and RTP should not be allowed)
are valid.

> We need
> to show an appropriate warning for all of them, and warning RTP vs SDES-SRTP
> vs unsigned DTLS-SRTP should not be very different. It should say "You are
> trying to communicate over unsecure peer--to-peer channel with an unknown
> party. Continue?" There is no, "you are trying to use slightly more secure
> channel. Is this ok?".

I don't entirely agree. In my example (the airport with open WiFi) the
signaling could be secured via HTTPS and the media secured with
SDES-SRTP. In this way other users in same open WiFi network cannot
monitor the signaling so they cannot get the SDES key, and therefore
they cannot monitor the SDES-SRTP stream. This is really better than
allowing plain RTP in an open WiFi network, am I wrong?

Regards.

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

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Sat, 17 Mar 2012 16:33:00 +0000

Tim,

I think that you miss the point of RTP and ICE are (IPSec) encrypted between (RTCWeb client) endpoint and Enterprise during VPN connection. So, RTP & ICE packets from endpoint are routed in WiFi ISP as IP packet with encrypted payload and no security issues.

Thanks
Partha

>From: Tim Panton [mailto:[email-masked]]
>Sent: Saturday, March 17, 2012 5:23 PM
>To: Ravindran, Parthasarathi
>Cc: Randell Jesup; [email-masked]
>> In my usecase, the application will not be able to access the website
>without VPN connection . Please explain your bid-down attack in my
>usecase.
>
>I think there probably is an vulnerability if Bob goes on line (to
>upgrade the call to video say) and happens to be on the same wifi ISP as
>Alice. The ICE probes may find a route between them that does not
>involve Alice's corporate VPN, but rather over the non-routable ISP's
>/16 network. This would result in RTP in the clear being visible on both
>parties local wifi.
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 17 Mar 2012 17:33:21 +0100

> In my usecase, the application will not be able to access the website without VPN connection . Please explain your bid-down attack in my usecase.

IMHO the topic here is not about finding a usecase in which using
plain RTP is secure (as in your example involving a VPN). Rather, the
topic is about finding common usecases in which the end user joins
unsecure media communications without the proper knowledge of "what
that means" so it accepts it. If the security depends on the end user
approval ("this web site does not provide secure audio/video
communications, do you accept it?") the we are lost (IMHO).

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 17 Mar 2012 09:37:58 -0700

> I think that you miss the point of RTP and ICE are (IPSec) encrypted between (RTCWeb client) endpoint and Enterprise during VPN connection. So, RTP & ICE packets from endpoint are routed in WiFi IS…

Partha,

I don't find the scenario you suggest particularly compelling.

Yes, it's true that it's more secure to run your communications over
a VPN than not, but it's not obviously the case that you necessarily
trust everyone who is on the VPN (after all, this is why companies
with VPNs run internal access controls on their systems). And it's
of course yet more secure to run point-to-point encryption even
when you are operating on a VPN.

With that said, even if we were to stipulate that the VPN case
is safe, you haven't explained why it's desirable not to cryptographically
protect the traffic in that case. Since it's easier and safer to
simply have only a secure mode of operation, I don't see
that this scenario is an argument in favor of RTP.

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Sat, 17 Mar 2012 12:40:04 -0400

On Fri, Mar 16, 2012 at 11:58 PM, Eric Rescorla <[email-masked]> wrote:

> unnecessary
> wish

Do you expect this done through some sort of desktop monitoring software or
does it mean that we need to design a network protocol for proxying WebRTC
media traffic? In case we need a recording proxy, we will need a protocol,
that on one hand, would allow the intermediary proxy to decode and monitor
all the traffic, and on the other hand would continue to work when
encryption and identity management is enabled. I am not sure something like
this is available, but, at the very least, it should include the mechanism
for a client to share the keys with the proxy.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 17 Mar 2012 17:40:43 +0100

> I think that you miss the point of RTP and ICE are (IPSec) encrypted between (RTCWeb client) endpoint and Enterprise during VPN connection. So, RTP & ICE packets from endpoint are routed in WiFi IS…

Wrong. During ICE processing the WebRTC will try to find out all its
local network interfaces for the ICE offer, and these include the VPN
interface along with the "normal" interface used for the default
gateway 0.0.0.0 / 0::0. So in case Bob is in the same open WiFi
network, ICE would success and plain RTP would be used in a network
than anyone can monitor.

However I don't understand what are you trying to say. Are you looking
for a single usecase in which plain RTP is secure? Then let's be easy
and explain an example in which a user has no Internet and home and
uses his laptop to access a Web/WebRTC server also at home. Should
WebRTC allow plain RTP just for that case?

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

---

From: Martin Thomson <[email-masked]>
Date: Sat, 17 Mar 2012 13:45:17 -0700

> for a client to share the keys with the proxy.

This isn't that hard.  I run an intercepting proxy that offers its own
certificate.  Then I explicitly place a trust anchor for that
certificate in your browser.  The proxy is then able to intercept any
encrypted traffic it chooses to.  The proxy does two lots of crypto
work, but that's not as much of a big deal as you might think.

No protocol changes at all.  The proxy might need to do more work to
convince you that the identity hasn't been replaced (swap itself in as
the identity provider, for example), but anything is possible once it
is "trusted".

--Martin

---

From: Igor Faynberg <[email-masked]>
Date: Sat, 17 Mar 2012 17:14:00 -0400

..

On 3/17/2012 4:45 PM, Martin Thomson wrote:
> ... Then I explicitly place a trust anchor for that
> certificate in your browser.

How?  I thought the browser would never allow that to happen. (I assumed 
it would come provisioned with anchors,  or would allow anchor provision 
through some different channel.)

Igor

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 17 Mar 2012 14:17:16 -0700

EKR said: 

> with VPNs run internal access controls on their systems). 

[BA] The NSA has made exactly this point:  it is not sufficient to run
unencrypted RTP over a VPN;  the signaling MUST be secured
(e.g. via TLS) and SRTP MUST also be used. 

I would also note that NSA allows use of SDES/SRTP over a VPN, since
this is widely support, even though this was not their originally favored solution 

For details, see:
http://www.theverge.com/2012/3/2/2838729/nsa-project-fishbowl-secure-android-devices-network

---

From: Martin Thomson <[email-masked]>
Date: Sat, 17 Mar 2012 14:31:49 -0700

On 17 March 2012 14:14, Igor Faynberg <[email-masked]> wrote:
> How?  I thought the browser would never allow that to happen. (I assumed it
> would come provisioned with anchors,  or would allow anchor provision

I own your computer.  Or I make it a condition of you adding your
computer to my network.

---

From: Igor Faynberg <[email-masked]>
Date: Sat, 17 Mar 2012 20:38:22 -0400

Ah, so this is the enterprise scenario.  I get it. Thanks!

This case though would not worry me much because when you own my 
computer you make me confirm that I understand that I should not expect 
any privacy whatsoever.

Igor

On 3/17/2012 5:31 PM, Martin Thomson wrote:
> On 17 March 2012 14:14, Igor Faynberg<[email-masked]>  wrote:

---

From: Roman Shpount <[email-masked]>
Date: Sun, 18 Mar 2012 22:20:36 -0400

> the identity provider, for example), but anything is possible once it
I understand how this will work with HTTPS, but how would this work with
WebRTC? Signaling is traveling over some separate path withing a websocket
or some other HTTP-based encapsulating protocol. Keys/Key signatures are
part of this signaling, which is almost impossible to intercept, even if
you have access to all HTTP(S) traffic, since each application can define
the protocol being used. Intercepting proxy needs access to this info, or
it cannot decode the media or spoof the signatures. Unless I am missing
something, client needs to send the SDP to the proxy and get the modified
SDP back, which probably requires some sort of network protocol.
_____________
Roman Shpount

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Sun, 18 Mar 2012 23:10:03 -0500

I would like to argue two points: 1) DTLS-SRTP with IdP is the only media security scheme that rtcweb should support; and 2) rtcweb should also support RTP (no media security) with a clear requirement on the browser UI to warn the user of the complete lack of media security.

DTLS-SRTP

Some of the arguments made against DTLS-SRTP in recent emails are valid unless it is integrated with trusted IdP that is sufficient to verify the identity of the remote party.  With this one caveat, DTLS-SRTP is equal to or (mostly) better than SDES-SRTP in almost all respects (not to be repeated here).  Even if the identity is suspect, the IdP can at least provide some degree of assurance and accountability when an issue arises.  Without that, a user has no recourse when a problem develops.

The key is that the browser UI must make clear to the user the identity of the remote party with whom media security has been established (even when it is a network gateway, in which case the identify of the gateway operator).  It should also be possible for the end user to mandate that a remote party identity is always verified before communication is allowed (perhaps even make this a requirement when media security is selected).  This is not too burdensome a requirement if established up front to help manage SPIT.

When end-to-end security is possible, then Alice knows that she's talking to Bob and vice versa.

Even when Alice is talking to someone reached via the PSTN, she can know that she has a secure media connection to a gateway owned by a particular (the identified) operator, thus establishing a significant part of the chain of accountability.  We can't improve on the security available through the PSTN, but we can improve on the security available to the point of interconnection with the identified operator (which may be different from the owner of the rtcweb application).  With DTLS-SRTP the user can have some basis for deciding whether to trust the identified operator; else (even with SDES-SRTP) you must completely trust the owner of the rtcweb application and there is no way to identify or verify any security attributes associated with the media.

Finally, there are multiple reasons to avoid supporting multiple media security schemes.  It is difficult enough to expect the end user to make sure they are comfortable with the identity of the remote party of a secure media connection, but to ask if they are comfortable with an alternative media security scheme is simply too much to expect.  Bid-down attacks are just too easy and it is impossible to verify any remote party identity with SDES-SRTP.

RTP

There are too many reasonable use cases for unsecured media for us to ignore them.  The browser should be very clear when media security is unavailable and make it easy to prevent communication without media security (perhaps as a default setting), but there are legitimate use cases in various private environments (e.g., enterprise, jail) where media security may not be allowed (or must somehow be compromised), or is just not available, that we should just support straight RTP.  As long as the user can control the conditions under which media security is disabled, I do not see a problem.

Richard Ejzak

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Mar 2012 00:21:28 -0400

+1
_____________
Roman Shpount

On Mon, Mar 19, 2012 at 12:10 AM, Ejzak, Richard P (Richard) <
[email-masked]> wrote:

> ** **
>
> I would like to argue two points: 1) DTLS-SRTP with IdP is the only media
> security scheme that rtcweb should support; and 2) rtcweb should also
> support RTP (no media security) with a clear requirement on the browser UI
> to warn the user of the complete lack of media security.****
>
> ** **
>
> DTLS-SRTP****
>
> ** **
>
> Some of the arguments made against DTLS-SRTP in recent emails are valid
> unless it is integrated with trusted IdP that is sufficient to verify the
> identity of the remote party.  With this one caveat, DTLS-SRTP is equal to
> or (mostly) better than SDES-SRTP in almost all respects (not to be
> repeated here).  Even if the identity is suspect, the IdP can at least
> provide some degree of assurance and accountability when an issue arises.
>  Without that, a user has no recourse when a problem develops.  ****
>
> ** **
>
> The key is that the browser UI must make clear to the user the identity of
> the remote party with whom media security has been established (even when
> it is a network gateway, in which case the identify of the gateway
> operator).  It should also be possible for the end user to mandate that a
> remote party identity is always verified before communication is allowed
> (perhaps even make this a requirement when media security is selected).
>  This is not too burdensome a requirement if established up front to help
> manage SPIT.  ****
>
> ** **
>
> When end-to-end security is possible, then ****Alice**** knows that she’s
> talking to Bob and vice versa.  ****
>
> ** **
>
> Even when ****Alice**** is talking to someone reached via the PSTN, she
> can know that she has a secure media connection to a gateway owned by a
> particular (the identified) operator, thus establishing a significant part
> of the chain of accountability.  We can’t improve on the security available
> through the PSTN, but we can improve on the security available to the point
> of interconnection with the identified operator (which may be different
> from the owner of the rtcweb application).  With DTLS-SRTP the user can
> have some basis for deciding whether to trust the identified operator; else
> (even with SDES-SRTP) you must completely trust the owner of the rtcweb
> application and there is no way to identify or verify any security
> attributes associated with the media.  ****
>
> ** **
>
> Finally, there are multiple reasons to avoid supporting multiple media
> security schemes.  It is difficult enough to expect the end user to make
> sure they are comfortable with the identity of the remote party of a secure
> media connection, but to ask if they are comfortable with an alternative
> media security scheme is simply too much to expect.  Bid-down attacks are
> just too easy and it is impossible to verify any remote party identity with
> SDES-SRTP.****
>
> ** **
>
> RTP****
>
> ** **
>
> There are too many reasonable use cases for unsecured media for us to
> ignore them.  The browser should be very clear when media security is
> unavailable and make it easy to prevent communication without media
> security (perhaps as a default setting), but there are legitimate use cases
> in various private environments (e.g., enterprise, jail) where media
> security may not be allowed (or must somehow be compromised), or is just
> not available, that we should just support straight RTP.  As long as the
> user can control the conditions under which media security is disabled, I
> do not see a problem.****
>
> ** **
>
> Richard Ejzak****
>
> ** **
>
> ** **
>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 19 Mar 2012 06:07:18 +0000

+1

I'll add more usecase to strengthen RTP usage in WebRTC.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: Monday, March 19, 2012 9:51 AM
To: Ejzak, Richard P (Richard)
Cc: [email-masked]
Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris

+1
_____________
Roman Shpount

On Mon, Mar 19, 2012 at 12:10 AM, Ejzak, Richard P (Richard) <[email-masked]<mailto:[email-masked]>> wrote:
I would like to argue two points: 1) DTLS-SRTP with IdP is the only media security scheme that rtcweb should support; and 2) rtcweb should also support RTP (no media security) with a clear requirement on the browser UI to warn the user of the complete lack of media security.

DTLS-SRTP

RTP

Richard Ejzak

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Randell Jesup <[email-masked]>
Date: Mon, 19 Mar 2012 04:54:09 -0400

On 3/19/2012 12:10 AM, Ejzak, Richard P (Richard) wrote:
> I would like to argue two points: 1) DTLS-SRTP with IdP is the only
> media security scheme that rtcweb should support; and 2) rtcweb should
> also support RTP (no media security) with a clear requirement on the
> browser UI to warn the user of the complete lack of media security.
>
> DTLS-SRTP

[SNIP]

I generally agree.

> security (perhaps as a default setting), but there are legitimate use
> cases in various private environments (e.g., enterprise, jail) where
> media security may not be allowed (or must somehow be compromised), or
> is just not available, that we should just support straight RTP. As long
> as the user can control the conditions under which media security is
> disabled, I do not see a problem.

The issue with "legacy" RTP is more one of controlling 'consent', such 
that we can avoid a WebRTC endpoint being used as a DDoS client.  I 
spent many hours trying to find a way around the issue, and only found 
ones that involve some level of modification to the target RTP client or 
its network (and still have serious issues).

For your case (not necessarily 'legacy', but needs-to-be-in-the-clear), 
perhaps there are other solutions.

One would be the command-line switch to force a NULL SRTP cipher.

An enterprise could use a WebRTC gateway, which in the context of WebRTC 
the user could provide their IdP credentials to (or the enterprise could 
be the IdP itself); or just act as a WebRTC MITM without bothering with 
IdP support.  Certainly there are usecases for keeping media traffic 
within an enterprise encrypted - I remember getting router-traffic dumps 
at an old company and being able to replay RTP conversations, including 
sensitive ones with external council, board members, HR, etc.  Modern 
switched setups make this tougher for J-random-employee to do, but far 
from impossible, and trivial for anyone working in networking IT or with 
physical access to switches or wiring.

-- 
Randell Jesup
[email-masked]

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 19 Mar 2012 12:38:01 +0100

2012/3/19 Ejzak, Richard P (Richard) <[email-masked]>:
> RTP
>
> There are too many reasonable use cases for unsecured media for us to ignore
> them.

Which ones? I just see one: interoperability with legacy SIP devices.
The question is: does it make sense to create a new specification
(WebRTC) less secure that it can be instead of forcing SIP vendors to
implement SRTP in their devices? If SIP vendors assumed that their
devices would just work in trusted networks (or wallen gardens) that
should not affect the security aspects of a new specification made for
*Internet*. That's their problem (SRTP was initially defined for SIP,
so they must do their homeworks).

Is plain RTP an advantage for WebRTC? Not at all since WebRTC
implementations will support SRTP by design so downgrading to plain
RTP is never better than using SRTP. Even if you use an VPN for your
enterprise WebRTC application there is NO problem at all in using SRTP
over the VPN.

So instead of anecdotal usecases in which plain RTP is "good enough" I
would prefer to read the truth: "I am a telco/vendor and I want WebRTC
(a specification originally designed for Internet) to support plain
RTP so I can make business with my legacy and not secure SIP devices,
those that don't implement SRTP regardless SRTP was designed for SIP".

> The browser should be very clear when media security is unavailable
> and make it easy to prevent communication without media security (perhaps as
> a default setting), but there are legitimate use cases in various private
> environments (e.g., enterprise, jail) where media security may not be
> allowed (or must somehow be compromised), or is just not available, that we
> should just support straight RTP.  As long as the user can control the
> conditions under which media security is disabled, I do not see a problem.

I assume that finally plain RTP will be allowed in WebRTC, too much
interest in interoperability with legacy and non secure SIP devices.
However, adding more and more "security approvals" for end users in
their web browsers is much worse than mandating security by design.

Regards.

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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 19 Mar 2012 05:14:11 -0700

> Which ones? I just see one: interoperability with legacy SIP devices.

[BA] Agreed.  And as we've already seen, SDES/SRTP support is prevalent enough among legacy devices that the legacy use case does not require RTP. 

> Even if you use an VPN for your enterprise WebRTC application there is NO problem at all in using SRTP
> over the VPN.

[BA] And in fact, this is exactly the NSA "Secure VoIP" architecture (with SDES/SRTP, by the way). 

> I can make business with my legacy and not secure SIP devices,

[BA] At this point, support for SRTP is an expected feature on legacy equipment.  For
example, all the leading PSTN gateway vendors support SRTP already.  By the time
RTCWEB specs are final, SRTP support will be very prevalent.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 19 Mar 2012 13:24:53 +0100

2012/3/19 Bernard Aboba <[email-masked]>:
> At this point, support for SRTP is an expected feature on legacy equipment.
> For example, all the leading PSTN gateway vendors support SRTP already.  By the time RTCWEB specs are final, SRTP support will be very prevalent.

And if they don't support SRTP then bad luck for them. WebRTC cannot
be less secure and worse just because some SIP legacy equipments don't
implement a specification from 2004 (RFC 3711 - SRTP) !!

Please, make WebRTC as secure as possible for common usages in the
open Internet, rather than decreasing the security just to get
interoperability with telcos non supporting SRTP.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 19 Mar 2012 14:29:27 +0100

2012/3/19 Ravindran, Parthasarathi <[email-masked]>:
> I’ll add more usecase to strengthen RTP usage in WebRTC.

Partha, instead of showing usecases in which SRTP is not fully
required (due to VPN existence or just localhost with no Internet
connection), please identify just a single usecase in which using SRTP
is *bad* or *worse* than using plain RTP. Just one.

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 19 Mar 2012 07:42:38 -0700

On Sat, Mar 17, 2012 at 4:52 AM, Tim Panton <[email-masked]> wrote:

> It's a slightly contrived case, but not impossible.
I don't think it's all that contrived, as I think we could see at an
IETF meeting pretty easily.  Alice and Bob go to their companies
intranet site to start their call, but ICE puts them both on the local
IETF lan, so RTP flows directly there.  Note that this could be the
case if they are simply screen sharing and typing in a chat--something
that they might be doing in order to have a back channel discussion
before a presentation.  I've certainly seen that happen at the IETF on
more than one occasion.

Ted

---

From: Ted Hardie <[email-masked]>
Date: Mon, 19 Mar 2012 07:50:48 -0700

On Sun, Mar 18, 2012 at 9:10 PM, Ejzak, Richard P (Richard)
<[email-masked]> wrote:
> to warn the user of the complete lack of media security.
>

I'd like to comment on the "browser UI" issue here.  As we have
discussed in the past, the users of this technology may very well
include applications which are not browsers.  In the "pokerstars"
example, a mobile device may very well be using a purpose-built
application instead of the mobile browser in order to reach the site.
These mobile apps may interact with web-browser based clients during
the same hand of poker.   If the web-browser based client wants to use
an insecure media channel and can get consent, there is still no
guarantee that other clients can do the same using the same UI
feature.

Web technology != browser.  Let's be careful not to build the security
story at the protocol level on UI features we can neither predict nor
control.  We can choose not to have certain levels of security, but
hand-waving that decision away because we believe it can be managed at
some other layer is a very risky proposition.

regards,

Ted

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 19 Mar 2012 15:57:22 +0100

+2 (I don't like "+1" since Google has decided to own it)

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 19 Mar 2012 08:19:09 -0700

On Mar 19, 2012 5:25 AM, "Iñaki Baz Castillo" <[email-masked]> wrote:
> > For example, all the leading PSTN gateway vendors support SRTP
already.  By the time RTCWEB specs are final, SRTP support will be very
prevalent.
> interoperability with telcos non supporting SRTP.

+1, srtp is required

And, it blows my mind this discussion is still going on.

If srtp is not mandatory, it creates a great deal more work for me (a telco
who has customers that expect privacy)

Cb

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Mon, 19 Mar 2012 11:00:59 -0500

Ted,
I simply do not buy your argument.

It doesn't matter what security scheme is used if you download a dedicated communications client that you don't trust.  It can play whatever games it wants with the UI and the security configuration and you are none the better off.  You have to trust the application.

It is only within the context of a trusted browser (and its UI) that any of this security work makes sense.  As long as you can trust the browser to tell you what's going on, you don't have to trust the application.

You might also have a trusted dedicated application but it better follow the same guidelines if it expects to remain trusted.

Richard

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Monday, March 19, 2012 9:51 AM
To: Ejzak, Richard P (Richard)
Cc: [email-masked]
Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris

regards,

Ted

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Mon, 19 Mar 2012 11:03:09 -0500

SRTP by itself guarantees nothing.  What is the point of insisting that the browser encrypt media if you know nothing about the other endpoint of the encrypted media or even whether anyone else has keys?

Richard

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cameron Byrne
Sent: Monday, March 19, 2012 10:19 AM
To: Iñaki Baz Castillo
Cc: [email-masked]
Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris

On Mar 19, 2012 5:25 AM, "Iñaki Baz Castillo" <[email-masked]<mailto:[email-masked]>> wrote:
>
> 2012/3/19 Bernard Aboba <[email-masked]<mailto:[email-masked]>>:

+1, srtp is required

If srtp is not mandatory, it creates a great deal more work for me (a telco who has customers that expect privacy)

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 19 Mar 2012 17:10:48 +0100

2012/3/19 Ejzak, Richard P (Richard) <[email-masked]>:
> SRTP by itself guarantees nothing.  What is the point of insisting that the
> browser encrypt media if you know nothing about the other endpoint of the
> encrypted media or even whether anyone else has keys?

If I am at the airport using an open WiFi connection, I visit a web
page using HTTPS and my browser validates the server TLS certificate,
neither I can be sure that the server has not been hacked by
attackers. But at least I know that nobody in the airport can monitor
my HTTPS traffic.

Indeed SRTP by itself guarantees nothing, but if the signaling path is
secured (HTTPS or WebSocket over TLS, so SRTP-SDES becomes a secure
solution) nobody in my network can intercept my media communication.
IMHO that's much better than nothing (plain RTP).

Regards.

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

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 19 Mar 2012 09:26:49 -0700

> IMHO that's much better than nothing (plain RTP).

No security tool ever guarantees anything.

They just increase the cost/time of hacking interception.

Cb

---

From: Tim Panton <[email-masked]>
Date: Mon, 19 Mar 2012 16:53:39 +0000

> SRTP by itself guarantees nothing.  What is the point of insisting that the browser encrypt media if you know nothing about the other endpoint of the encrypted media or even whether anyone else has…

If you are in an airport lounge, it should mean the script kiddie at the next gate over has a harder time reading your screenshare.
Admittedly you are only incrementally securing the first hop, but often - to coin a phrase - "the first hop is the weakest" ;-)

Tim.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 19 Mar 2012 10:08:51 -0700

On Mon, Mar 19, 2012 at 9:00 AM, Ejzak, Richard P (Richard)
<[email-masked]> wrote:
> It doesn't matter what security scheme is used if you download a dedicated
> communications client that you don't trust.  It can play whatever games it
> wants with the UI and the security configuration and you are none the
> better off.  You have to trust the application.

Obviously, I have not expressed myself well.  If I have a downloaded
application for playing poker which includes WebRTC, I have a fairly fixed UI.
Advice given to browsers on how to reflect that a particular
connection has lower than usual security characteristics is likely
useless to that application UI designer, and the likelihood of a
consistent UI across multiple downloaded applications for "the other
endpoint wants unprotected media" is pretty close to zero.

In cases where you have both browsers and downloaded apps, you cannot
allow browsers to set the ravish-me bits for the flow because you
believe they gave consent *without creating a problem for the
downloaded apps and their users*.  Each one of the downloaded apps has
to invent a UI marker for this, and the user has to understand what
each marker means in its context for this to be successful.  That's
not nearly as tractable as getting Chrome, Safari, Mozilla, IE, Opera,
and friends to agree what belongs in browser chrome.

regards,

Ted

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Mar 2012 13:13:21 -0400

On Mon, Mar 19, 2012 at 12:53 PM, Tim Panton <[email-masked]> wrote:

> SRTP by itself guarantees nothing.  What is the point of insisting that
> the browser encrypt media if you know nothing about the other endpoint of
> the encrypted media or even whether anyone else has keys?
> ****
>
>
> If you are in an airport lounge, it should mean the script kiddie at the
> next gate over has a harder time reading your screenshare.
> Admittedly you are only incrementally securing the first hop, but often -
> to coin a phrase - "the first hop is the weakest" ;-)
>
> Tim.
>
>
In this case the simplest way to compromise your security is to seat next
to you. Your first hop is between your mouth and the microphone. Or between
your screen and your face.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 19 Mar 2012 18:20:12 +0100

2012/3/19 Roman Shpount <[email-masked]>:
> In this case the simplest way to compromise your security is to seat next to
> you. Your first hop is between your mouth and the microphone. Or between

You can control that (you know whether there is people hearing you or
not, or at least you can check it). But if you are using plain RTP in
an open WiFi connection you have no way to determine whether somebody
in the floor above/below is intercepting your RTP.

If your argument would be valid, then HTTPS is useless since somebody
could seat near you and watch your screen. Ok, let's focus the real
discussion...

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

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Mar 2012 14:15:35 -0400

I guess my question is, when are we going to tell the user that connection
is "secure"? What I really do not want is making the distinction between
secured and unsecured connection so muddy, that a normal user will never be
able to understand the difference and will agree to anything. Because of
this, I would like to see that if connection is over DTLS-SRTP with a
remove party verified by an identity provider, user would be asked if they
would like to communicate with remote party XYZ. If this is anything else,
(DTLS-SRTP with no identity, SDES-SRTP, or even plain RTP), user should be
asked either to allow unsecure communication with an unknown party, or,
completely prohibited to do so.

I do not see the difference, as far as security is concerned, between
SDES-SRTP and plain RTP. If we allow SDES-SRTP for compatibility reasons,
we might as well allow plain RTP. It would be compatible with more devices
and as insecure as SDES-SRTP. There is no requirement that WebRTC
application must use HTTPS for signaling. If the application is using HTTP,
all the "sitting in the airport" examples are as unsecured with SDES-SRTP
as they are with plain RTP.

I do not think we would be able to force WebRTC application developers to
create a secure application unless they would decide to create care and
effort to develop it as such. Our goal should be to provide application
developers with tools that would allow them to create secure applications
and with mechanisms that would allow users to identify when their
communications are actually secure. Everything else is just adding random
requirements to the standard.
_____________
Roman Shpount

---

From: Tim Panton <[email-masked]>
Date: Mon, 19 Mar 2012 18:35:16 +0000

On 19 Mar 2012, at 18:15, Roman Shpount wrote:

> I do not see the difference, as far as security is concerned, between SDES-SRTP and plain RTP. If we allow SDES-SRTP for compatibility reasons, we might as well allow plain RTP. It would be compatible with more devices and as insecure as SDES-SRTP. There is no requirement that WebRTC application must use HTTPS for signaling. If the application is using HTTP, all the "sitting in the airport" examples are as unsecured with SDES-SRTP as they are with plain RTP.

How many of these plain RTP only legacy devices support password verified ICE correctly? - I'd be shocked if you found _any_. 

With JSEP there is nothing to stop the application from encrypting the SDP blob in javascript before forwarding it to the far end 
over HTTP - not my preferred option, but technically possible, and it would definitely make a firesheep style attack a bit harder to 
pull off.

Tim.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Mar 2012 14:44:17 -0400

On Mon, Mar 19, 2012 at 2:35 PM, Tim Panton <[email-masked]> wrote:

> How many of these plain RTP only legacy devices support password verified
> ICE correctly? - I'd be shocked if you found _any_.
>
>
And how many of the SDES-SRTP devices support password verified ICE? I
doubt you would find any of them either. So, why is SDES-SRTP is OK and RTP
is not?

> With JSEP there is nothing to stop the application from encrypting the SDP
> blob in javascript before forwarding it to the far end
> over HTTP - not my preferred option, but technically possible, and it
> would definitely make a firesheep style attack a bit harder to pull off.
>
>
Once again, my point was that application developer would need to properly
develop signaling application (ie deliver it over HTTPS; don't put
encryption keys into something that can be easily accessable, etc). Unless
a lot of care is taken, SDES-SRTP is not secure.

Why do we need to support SDES-SRTP at all? I do not understand the
arguments that say RTP is bad, but SDES-SRTP is ok. If you need interop,
RTP is your best option. If you need security DTLS-SRTP is your answer.
SDES-SRTP does not serve either purpose well.
_____________
Roman Shpount

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 19 Mar 2012 14:47:23 -0400

This is the question that I have been asking for a while...  I don't 
expect a complete fireproof answer, of course, and I also understand 
that the browser today is telling me a few things about the security of 
a site and warns me when "the site is trying to access the data it 
should not be accessing."

But I  also imagine that a rogue site could display a message mimicking 
the security assurance as though it comes from the browser.

So it would be good to have a very clear idea when  the determination 
about the security of the connection and such is made and how the end 
user can verify that it actually comes from the browser.

(To this end, the user MUST trust the browser, of course.)

Igor

On 3/19/2012 2:15 PM, Roman Shpount wrote:
> I guess my question is, when are we going to tell the user that 
> connection is "secure"?...

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 19 Mar 2012 20:47:41 +0100

2012/3/19 Roman Shpount <[email-masked]>:
> encryption keys into something that can be easily accessable, etc). Unless a
> lot of care is taken, SDES-SRTP is not secure.

Again in the airport with open WiFi:

- If you use SDES-SRTP and HTTPS (or secure WebSocket), so SDES keys
are not interceptable in the WiFi network, you can be sure that no one
in the airport can monitor your media (I assume the server is not
hacked by a person in the same airport!).

- If you use plain RTP you know that every one in the airport can
monitor your media (regardless there is TLS in the signaling path or
not).

> Why do we need to support SDES-SRTP at all?

In conjunction with a secure signaling path (HTTPS or secure
WebSocket) IMHO it provides a reasonable security level for avoiding
media interception.

> I do not understand the
> arguments that say RTP is bad, but SDES-SRTP is ok.

Replied above.

> If you need interop, RTP
> is your best option. If you need security DTLS-SRTP is your answer.

I'm not a fan of SDES-SRTP, I just say that IMHO it can provide a good
security level.

The only I say is that there is no reason for allowing plain RTP other
than interop with old/legacy SIP devices (those whose vendors have
decided not to implement SRTP, a spec from 2004). Is there any other
case in which using plain RTP within WebRTC context is better than
using SRTP?

Regards.

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

---

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 19 Mar 2012 20:52:07 +0100

On Mon, 19 Mar 2012 20:47:41 +0100

> case in which using plain RTP within WebRTC context is better than

Large scale public events come to mind.

L.

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

---

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 19 Mar 2012 20:55:20 +0100

On Mon, 19 Mar 2012 20:52:07 +0100

> Large scale public events come to mind.

(even though, thinking about it, they're probably out of scope in here)

L.

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Mar 2012 16:08:29 -0400

> case in which using plain RTP within WebRTC context is better than
Is there any case in which using SDES-SRTP is better then using DTLS-SRTP,
except interop with old/legacy devices?
_____________
Roman Shpount

---

From: Tim Panton <[email-masked]>
Date: Mon, 19 Mar 2012 20:31:39 +0000

> Large scale public events come to mind.

Assuming that you are thinking of the CPU required to encrypt all the streams, 
I see no reason you couldn't have all the streams use the same keys, the you could
write a special SRTP stack that encoded exactly once then echoed the same packets to all the recipients.

(Which is close to the case for satellite TV at the moment I believe).

T.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 19 Mar 2012 22:04:21 +0100

2012/3/19 Roman Shpount <[email-masked]>:
>> Is there any other

Mandating DTLS-SRTP (this is, not allowing plain RTP neither
SDES-SRTP) is not a problem for me. :)

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 19 Mar 2012 21:36:47 +0000

On Mar 19, 2012, at 4:08 PM, Roman Shpount wrote:

> Is there any case in which using SDES-SRTP is better then using DTLS-SRTP, except interop with old/legacy devices?

Yup.  The other advantages of SDES are:
1) Shorter call-answer-delay, because there're no additional round-trips before media other than ICE
2) Cheaper/less-overhead/better-scaling
3) Fewer interop issues - we don't know what DTLS-SRTP interop issues will exist, if any, but more code usually means more interop issues, or at least more "bugs".  ICE itself will probably have some issues anyway[*], but more code and complexity won't help matters.

And if the Identity-model stuff is mandatory to use for DTLS, you can multiply the impact of those factors by some non-zero multiple.

-hadriel
[*] There are already multiple variants of ICE in the wild, with one implementation known not to interop with others.  But I don't know if it's an SDP-specific ICE interop issue or a problem with the connectivity checks or state machine.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 19 Mar 2012 22:23:55 +0000

While I sympathize with the concern that requiring SRTP (regardless of how the key is learned) is a burden for those use-cases that literally don't care about SRTP and for which it does not matter, such as a weather announcement service or an IETF meeting broadcast, I really think you're 'throwing out the baby with the bath-water' to propose we either get everything or nothing.  People won't have the identity-stuff for some time, and it won't be painless to make it work and deployed.  So what you're basically saying is "you only get RTP because you can't prove end-to-end security".  But such "proof" rarely exists even today.

Today, when you do Email or IM over HTTPS or SMTPS, that email or IM only goes secure to the server you're doing SMTPS or HTTPS with.  You have no assurance whatsoever that it stays secure from that point on, nor that the server doesn't log the email/IM in its entirety.  But that doesn't mean there's no value in using HTTPS/SMTPS to reach that first server.  Quite the contrary, there's significant value in it.  Just like there's value in using HTTPS to reach a web store-front when purchasing using a credit-card, even though you have no idea what the security is between the web-store and your actual credit-card company.

In the WebRTC context, for example, I would expect a quite-popular use-case for WebRTC to be Business websites, such as web-storefronts, or customer-support sites, or airline/hotel ticket/reservations/upgrades sites, etc.  When connecting to the web-page of those sites, I would expect them to be HTTPS once I got to some point of the click-flow process, if not from the beginning.  If I click a "talk to us for help" button, I would expect that to be secure as well, as much as the HTTPS portion was anyway.  In this context, only allowing them to use RTP is silly.  SDES is reasonably secure in this context, because there is no other domain the call is going to.  Yes, they have my SRTP key - doesn't matter; yes they can log my call - doesn't matter.  But at least my media is secure from my laptop to their server's domain - and that does matter, and it's all I ever got from using HTTPS.

-hadriel

On Mar 19, 2012, at 2:15 PM, Roman Shpount wrote:

> I guess my question is, when are we going to tell the user that connection is "secure"? What I really do not want is making the distinction between secured and unsecured connection so muddy, that a normal user will never be able to understand the difference and will agree to anything. Because of this, I would like to see that if connection is over DTLS-SRTP with a remove party verified by an identity provider, user would be asked if they would like to communicate with remote party XYZ. If this is anything else, (DTLS-SRTP with no identity, SDES-SRTP, or even plain RTP), user should be asked either to allow unsecure communication with an unknown party, or, completely prohibited to do so. 
> 
> I do not think we would be able to force WebRTC application developers to create a secure application unless they would decide to create care and effort to develop it as such. Our goal should be to provide application developers with tools that would allow them to create secure applications and with mechanisms that would allow users to identify when their communications are actually secure. Everything else is just adding random requirements to the standard.
> _____________
> Roman Shpount
> 
>

---

From: "Jim Barnett" <[email-masked]>
Date: Mon, 19 Mar 2012 15:49:28 -0700

On the matter of the call center/travel site recording your call:  can't
the far-end user agent always record your call, no matter what security
you use?  So in the case of SDES, the call center can record at their
SBC/switch/media server (their in-house MITM), which is easier for them,
but even with DTLS/SRTP couldn't they always record it at the agent
desktop, if they wanted to?

- Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hadriel Kaplan
Sent: Monday, March 19, 2012 6:24 PM
To: Roman Shpount
Cc: [email-masked]
Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris

While I sympathize with the concern that requiring SRTP (regardless of
how the key is learned) is a burden for those use-cases that literally
don't care about SRTP and for which it does not matter, such as a
weather announcement service or an IETF meeting broadcast, I really
think you're 'throwing out the baby with the bath-water' to propose we
either get everything or nothing.  People won't have the identity-stuff
for some time, and it won't be painless to make it work and deployed.
So what you're basically saying is "you only get RTP because you can't
prove end-to-end security".  But such "proof" rarely exists even today.

Today, when you do Email or IM over HTTPS or SMTPS, that email or IM
only goes secure to the server you're doing SMTPS or HTTPS with.  You
have no assurance whatsoever that it stays secure from that point on,
nor that the server doesn't log the email/IM in its entirety.  But that
doesn't mean there's no value in using HTTPS/SMTPS to reach that first
server.  Quite the contrary, there's significant value in it.  Just like
there's value in using HTTPS to reach a web store-front when purchasing
using a credit-card, even though you have no idea what the security is
between the web-store and your actual credit-card company.

In the WebRTC context, for example, I would expect a quite-popular
use-case for WebRTC to be Business websites, such as web-storefronts, or
customer-support sites, or airline/hotel ticket/reservations/upgrades
sites, etc.  When connecting to the web-page of those sites, I would
expect them to be HTTPS once I got to some point of the click-flow
process, if not from the beginning.  If I click a "talk to us for help"
button, I would expect that to be secure as well, as much as the HTTPS
portion was anyway.  In this context, only allowing them to use RTP is
silly.  SDES is reasonably secure in this context, because there is no
other domain the call is going to.  Yes, they have my SRTP key - doesn't
matter; yes they can log my call - doesn't matter.  But at least my
media is secure from my laptop to their server's domain - and that does
matter, and it's all I ever got from using HTTPS.

-hadriel

> I guess my question is, when are we going to tell the user that
connection is "secure"? What I really do not want is making the
distinction between secured and unsecured connection so muddy, that a
normal user will never be able to understand the difference and will
agree to anything. Because of this, I would like to see that if
connection is over DTLS-SRTP with a remove party verified by an identity
provider, user would be asked if they would like to communicate with
remote party XYZ. If this is anything else, (DTLS-SRTP with no identity,
SDES-SRTP, or even plain RTP), user should be asked either to allow
unsecure communication with an unknown party, or, completely prohibited
to do so. 
> I do not see the difference, as far as security is concerned, between
SDES-SRTP and plain RTP. If we allow SDES-SRTP for compatibility
reasons, we might as well allow plain RTP. It would be compatible with
more devices and as insecure as SDES-SRTP. There is no requirement that
WebRTC application must use HTTPS for signaling. If the application is
using HTTP, all the "sitting in the airport" examples are as unsecured
with SDES-SRTP as they are with plain RTP.
> 
> I do not think we would be able to force WebRTC application developers
to create a secure application unless they would decide to create care
and effort to develop it as such. Our goal should be to provide
application developers with tools that would allow them to create secure
applications and with mechanisms that would allow users to identify when
their communications are actually secure. Everything else is just adding
random requirements to the standard.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Mar 2012 19:34:16 -0400

Here are the levels of security that we get right now:

1. DTLS SRTP with Identity provider with signaling over HTTP or HTTPS. As
long as identity provider is not compromised, user knows who they are
talking to and that conversation is reasonably secure.

2. DTLS SRTP or SDES SRTP with signaling over HTTPS. There are no
guarantees on who exactly the user is talking to, but as long we assume
that web server and javascript applications are not compromised,
conversation is secured to some application selected destination. Cannot
tell the user that the call is secure, but probably not going to be
something that can be picked up by a script kiddy with a network sniffer.

3. DTLS SRTP or SDES SRTP with signaling over HTTP. There are no guarantees
on where the application came from or who exactly you are talking to. The
conversation is encrypted, but it can either be listened to by simply
capturing the keys (SDES SRTP) or you can spoof DNS and take over the whole
web application and make DTLS SRTP talk to some sort of monitoring proxy.
No security and probably not much better then plain RTP.

So, my question is, are we going to disable WebRTC from HTTP initiated
sessions completely and show the appropriate UI confirmations (secure for 1
and unsecure for 2) or do we plan to do something different? If we allow
any non identity non DTLS SRTP communications with signaling over HTTP, we
might as well allow all of them. All of those communication modes will have
the same security downsides, and I would argue that RTP have probably the
most upsides.
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Mar 2012 17:18:37 -0700

On Mon, Mar 19, 2012 at 4:34 PM, Roman Shpount <[email-masked]> wrote:
> 2. DTLS SRTP or SDES SRTP with signaling over HTTPS. There are no guarantees
> on who exactly the user is talking to, but as long we assume that web server
> and javascript applications are not compromised, conversation is secured to
> some application selected destination. Cannot tell the user that the call is
> secure, but probably not going to be something that can be picked up by a
> script kiddy with a network sniffer.

As discussed in draft-ietf-rtcweb-security, I don't agree that DTLS-SRTP without
identity and SDES-SRTP offer the same level of security. Most of what I have
to say about that is already said there, but briefly:

- DTLS-SRTP is secure against retrospective attack whereas SDES-SRTP is not.
- If there is a mechanism such as fingerprints *is* available for
checking against
MITM, then DTLS-SRTP is secure against active attack as well. Additionally,
the existence of fingerprint type mechanisms acts as a partial deterrent against
MITM attack by the signaling provider even if only a small number of people
check.

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Mar 2012 20:59:05 -0400

> MITM attack by the signaling provider even if only a small number of people
I agree with you on all of those points. I would prefer that instead of
SDES SRTP support we spent time optimizing DTLS/ICE handshake (and there
are a few drafts on this list related to that). It should be possible to
conduct a secure key exchange at the same time as ICE candidate selection
with no additional overhead. I also understand the argument that most of
the regular users will never check the fingerprint, and this is why I put
SDES-SRTP and DTLS-SRTP in the same group. DTLS-SRTP is more secure then
SDES-SRTP, but it still not enough to tell the user that communication is
secure.

But regardless of all these points, if we allow signaling over HTTP all the
security considerations go out of the window.

For me the ideal solution is:

1. DTLS-SRTP with Identity and any signaling is always allowed and shows
notification that communication is with a known party and secure.
2. DTLS-SRTP with signaling over HTTPS shows notification that
communication is unsecure and with an unknown party
3. SDES SRTP is not supported at all and DTLS/ICE handshake is optimized
instead to reduce call setup time
4. DTLS-SRTP with no ident and RTP with signaling over HTTP are not
recommended, but allowed after a big red sign (or require some advanced
browser setting to enable).

I would also like to have a simplified DTLS specification for DTLS-SRTP,
with as many as possible unnecessary features (encryption algorithms,
cookies and such) removed and only a few required scenarios supported. For
instance, I do not want DTLS on a WebRTC channel start negotiation and end
up with anything except SRTP as an encryption protocol. Ideally, I want
something were an interop test can be developed with a manageable number of
scenarios.

P.S. Sending RSA public key in the session description instead of
fingerprint and then encrypting the SRTP key using this public key and
sending it in the ICE message might be a much simpler call setup mechanism
to implement then bringing the whole DTLS into the stack. This should also
allow us to setup a secure call with no overhead in addition to ICE.
_____________
Roman Shpount

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 20 Mar 2012 01:15:54 +0000

Jim,

As a customer, you won't really know whether the identity (DTLS-SRTP) of call center/travel site is agent or SBC. SBC can perform MITM attack easily as extending SDES-SRTP to DTLS-SRTP for call center site is feasible.

Thanks
Partha

>Of Jim Barnett
>Sent: Tuesday, March 20, 2012 4:19 AM
>To: Hadriel Kaplan; Roman Shpount
>Cc: [email-masked]
>In the WebRTC context, for example, I would expect a quite-popular use-
>case for WebRTC to be Business websites, such as web-storefronts, or

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 20 Mar 2012 01:53:02 +0000

Hi all,

Could you please let me know the reason why SRTP-DTLS alone MUST be supported by WebRTC web-browser and why not RTP-IPSec. In case my device support IPSec for all application, why web-browser has to mandated for double encryption. Another assumption here is that web-browser is endpoint (commercial browsers like chrome) which is not required as access entity (like Enterprise access router, SBC) shall acts as web-browser. So, web-browser point-to-point connection may be between employee browser to Enterprise access entity which is not required to be mandated as SRTP-DTLS. Hadriel mentioned large set of call centre solution wherein web-browser is just the endpoint, one way to access call centre and there is no need to change whole call centre architecture for the same WebRTC technology in case RTP-IPSec is supported by WebRTC browser running in IPSec mobile phone. I disagree with security advocates that all call centre using RTP will be broken as this security story does not sell well in the industry so far.

Also, It is impossible to have the common UI by all web-browser and IETF specification should not try to find the way to solve that issue. 

My problem is not mandatory to implement SRTP-DTLS but the issue is at mandatory to use. IMO, RTP-IPSec should be allowed with user-consent in web-browser and don't argue that all web user in the world are dumb. In case the usecase is missing for RTP-IPSec as Randell mentioned, let us discuss in IETF-83 RTCWeb meeting.

Thanks
Partha

>Sent: Tuesday, March 20, 2012 3:54 AM
>To: Roman Shpount
>Cc: [email-masked]

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Mar 2012 22:29:15 -0400

The reason is quite simple actually -- it is quite difficult to confirm
that IPSec is actually present. So browser has no way to determine that it
communicating over IPSec or plain IP.

On the other hand, I actually agree that if we are dealing with an
application on a private IP (like 10.X.X.X) you should be allowed to do
whatever you want. This is why I am proposing to support RTP for
applications delivered over HTTP. If you are in completely secure
environment and you do not want to do encryption, there is no reason why
the application should be delivered over HTTPS. If application is delivered
over HTTP, you either do no care about security (you are calling a public
radio) or security is provided by something else (you are sitting in the
bunker on the network not connected to the internet).

The large contingent of people on this list are convinced that upsides
(security) of requiring encryption outweigh downsides. The mentioned
downsides are:
1. Extra resource requirements. This is not really important as far as I am
concerned. New Xeon server can encrypt 39.7 GB/sec (
http://www.theregister.co.uk/2012/03/06/intel_xeon_e5_launch_event/)
2. Support for legacy devices. Also not as important since most legacy
devices will require a media proxy to support ICE anyway
3. Barrier to entry to develop new services. It is harder to debug and
develop new products if you need to develop larger number of protocols at
once. The understanding is that web browser will include some sort of
hidden setting that will allow plain RTP for debugging and development.
4. Encryption can be illegal or not allowed in some places, such as
military or prisons. Proposal is to enable some sort of configuration in
the web browser that will force it to send all the media through some sort
of recording/monitoring proxy.

While, as far as I am concerned, all of those arguments are addressed, my
main argument against requiring encryption is that there are scenarios when
it is not needed and not actually provided, primarily when application is
delivered over HTTP. All I am saying that if application developer does not
care about security, the application most likely would not be secure,
regardless of what we do. So why force it? Unless developer takes an effort
to buy an SSL certificate and deploy an app on a secure server, or gets the
certificate and sets up an identity provider, communication is not going to
be secure. If I am a high school kid trying to play with real time
communications using a free web hosting provider, I do not care about
security. All I care is that I can write something that makes a call. What
we are effectively doing is making this much more difficult. Innovation
does not have to come from serious projects created for serious purposes.
It often comes from things that are cobbled together and I want us to
enable this, unless it actually breaks something. I want to make WebRTC
easier to play with and hope that new exciting things will come out of this.
_____________
Roman Shpount

On Mon, Mar 19, 2012 at 9:53 PM, Ravindran, Parthasarathi <
[email-masked]> wrote:

> Hi all,
>
> Could you please let me know the reason why SRTP-DTLS alone MUST be
> supported by WebRTC web-browser and why not RTP-IPSec. In case my device
> support IPSec for all application, why web-browser has to mandated for
> double encryption. Another assumption here is that web-browser is endpoint
> (commercial browsers like chrome) which is not required as access entity
> (like Enterprise access router, SBC) shall acts as web-browser. So,
> web-browser point-to-point connection may be between employee browser to
> Enterprise access entity which is not required to be mandated as SRTP-DTLS.
> Hadriel mentioned large set of call centre solution wherein web-browser is
> just the endpoint, one way to access call centre and there is no need to
> change whole call centre architecture for the same WebRTC technology in
> case RTP-IPSec is supported by WebRTC browser running in IPSec mobile
> phone. I disagree with security advocates that all call centre using RTP
> will be broken as this security story does not sell well in the industry so
> far.
>
> Also, It is impossible to have the common UI by all web-browser and IETF
> specification should not try to find the way to solve that issue.
>
> My problem is not mandatory to implement SRTP-DTLS but the issue is at
> mandatory to use. IMO, RTP-IPSec should be allowed with user-consent in
> web-browser and don't argue that all web user in the world are dumb. In
> case the usecase is missing for RTP-IPSec as Randell mentioned, let us
> discuss in IETF-83 RTCWeb meeting.
>
> Thanks
> Partha
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Mar 2012 03:20:46 +0000

And, it should be noted, they *want* it that way.  They don't generally want you to know which agent picked up the call, or that the call got transferred from an IVR to a specific agent, or got put in a queue with elevator-music announcement server, or any of that.  You "called" Travel Co., and they answered.  What goes on behind that SBC is equivalent to the back-end database stuff that goes on between the web server and back-end systems, while all you see is the web-server your browser happens to be connected to.  

The "identity" you'll get is www.travel.co, which you already had when your browser did HTTPS cert verification of their web-server.  HTTPS became the key-exchange transport for the SRTP key.  Since they already proved they own the cert for www.travel.co, having them claim to be www.travel.co shouldn't require yet more verification.

-hadriel

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 20 Mar 2012 08:52:13 +0000

Bernard,

In case you expect SRTP-DTLS implementation will be prevalent during RTCWeb specification publication, I seriously doubt it.

Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Monday, March 19, 2012 5:44 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 20 Mar 2012 11:06:51 +0100

Hi,

Completely agree with Hadriel's statement below.

In addition to wanting to know that you are connected to "www.travel.co" or "www.mybank.co" you as a consumer and the company really want/need the media to be recorded by the companies system for your own protection. This is going to involve some kind of MITM or as we call it in SIPREC a Session Recording Client (SRC) to be able to intercept the media and route it to a Session Recording Server (SRS). 

The agent's desktop device could act as the SRC but more likely it will be some kind of B2BUA that does this.  

In these scenario's you as a consumer using this service really want the media to be secure at least as far as reaching the bank but after that like any existing web based system you have to trust the bank with your data this is no different whether that data is speech or text that you entered on a web page.

The recording system should be able to work with DTLS-SRTP but it will most likely act as a MITM so will change the DTLS fingerprint. I don't see that as a problem.

Regards
Andy

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hadriel Kaplan
> Sent: 20 March 2012 03:21
> And, it should be noted, they *want* it that way.  They don't generally
> want you to know which agent picked up the call, or that the call got
> transferred from an IVR to a specific agent, or got put in a queue with
> elevator-music announcement server, or any of that.  You "called"
> Travel Co., and they answered.  What goes on behind that SBC is
> equivalent to the back-end database stuff that goes on between the web
> server and back-end systems, while all you see is the web-server your
> browser happens to be connected to.
> 
> The "identity" you'll get is www.travel.co, which you already had when
> your browser did HTTPS cert verification of their web-server.  HTTPS
> became the key-exchange transport for the SRTP key.  Since they already
> proved they own the cert for www.travel.co, having them claim to be
> www.travel.co shouldn't require yet more verification.
> 
> -hadriel
> 
> 
> > As a customer, you won't really know whether the identity (DTLS-SRTP)
> of call center/travel site is agent or SBC. SBC can perform MITM attack
> easily as extending SDES-SRTP to DTLS-SRTP for call center site is
> feasible.
> >
> > Thanks
> > Partha
>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 20 Mar 2012 11:41:29 +0100

On 03/17/2012 10:14 PM, Igor Faynberg wrote:
> How?  I thought the browser would never allow that to happen. (I 
> assumed it would come provisioned with anchors,  or would allow anchor 
> provision through some different channel.)
>
Igor,

in Chrome, go to chrome://settings/certificates, choose the 
"authorities" tab, and note the presence of the "import" button.

All browsers (as far as I know) have similar mechanisms.
"Owning" your computer will achieve this goal both in its corporate 
meaning and in its hacker meaning.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 20 Mar 2012 11:52:51 +0100

I believe I have said this before, but...

We should never tell the user the connection is secure.
We should tell the user when we know he's exposed to risks that he 
usually isn't.

Thus - we should not give any indication that we're using DTLS-SRTP with 
verified identities (if that's what we normally support). We SHOULD give 
a warning saying "hey, since the gateway you've connected to isn't doing 
normal authentication procedures, but instead insists on exchanging keys 
on the signalling channel, you are less sure who you're talking to than 
usual, and there are more boxes that might record your call in the way, 
but the script kiddie on your hotel WLAN still can't see your packets 
(translation: legacy SDES key exchange is in use, but SRTP is still on).

All this will of course be iconified into a single cryptic graphic 
probably involving a padlock :-)

On 03/19/2012 07:47 PM, Igor Faynberg wrote:
> that the browser today is telling me a few things about the security 
> of a site and warns me when "the site is trying to access the data it 
> But I  also imagine that a rogue site could display a message 
> mimicking the security assurance as though it comes from the browser.
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 20 Mar 2012 04:03:17 -0700

> The recording system should be able to work with DTLS-SRTP but it will most likely act as a MITM so will change the DTLS fingerprint. I don't see that as a problem.

[BA] One of the questions I have had about the usage of DTLS-SRTP contemplated in RTCWEB is whether it will be interoperable with the SIP usage of DTLS-SRTP.  

In the SIP framework it is possible to do RFC 4474 re-signing in the B2BUA if the destination is an E.164 number. 

However, the DTLS-SRTP/IdP framework seems to assume that the identities are email-style addresses.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 20 Mar 2012 12:20:10 +0100

> allow us to setup a secure call with no overhead in addition to ICE.

Would this DTLS-SRTP simplification interoperate with other
technologies also implementing DTLS-SRTP+SDP?

AFAIK there are (not yet) SIP devices supporting DTLS-SRTP (maybe I'm
wrong), however my question is: once there are SIP implementations (or
Jingle ones implementing DTLS-SRTP) would those implementations
interoperate with your simplified version of DTLS for WebRTC?

Regards.

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

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Mar 2012 09:40:37 -0400

Once again, I understand how this helps in case of HTTPS, but how would
this help in case of WebRTC? Media description is carried in some sort of
application defined protocol (can even be transmitted over an encrypted
SCTP data channel or encrypted in javaScript), so monitoring proxy cannot
reliably modify it. I understand how it can be allowed to fake the
signature on modified SDP by inserting a certificate in the browser, but
how would the proxy get to the SDP in the first place?
_____________
Roman Shpount

On Tue, Mar 20, 2012 at 6:41 AM, Harald Alvestrand <[email-masked]>wrote:

> **
> in Chrome, go to chrome://settings/certificates, choose the "authorities"
> tab, and note the presence of the "import" button.
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 20 Mar 2012 14:48:33 +0100

2012/3/20 Roman Shpount <[email-masked]>:
> Once again, I understand how this helps in case of HTTPS, but how would this
> help in case of WebRTC? Media description is carried in some sort of
> application defined protocol (can even be transmitted over an encrypted SCTP
> data channel or encrypted in javaScript), so monitoring proxy cannot
> reliably modify it. I understand how it can be allowed to fake the signature
> on modified SDP by inserting a certificate in the browser, but how would the
> proxy get to the SDP in the first place?

That's up to the implementor, is not? This is: if a WebRTC provider
wants to monitor the media by modifying the SDP it should design some
system in which the SDP is carried by its systems (i.e. via HTTP(s) or
WebSocket).

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

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Mar 2012 09:50:39 -0400

> interoperate with your simplified version of DTLS for WebRTC?
There are actually two different options that I am proposing here.
Simplified DTLS-SRTP is just a clarification on what encryption protocols
and features are supported. Interop would be no different then interop with
DTLS-SRTP implementation which would require certificate validation. If one
of the parties request the feature not supported by the other, DTLS
handshake fails and connection would not be established.

The other proposal was not to use DTLS at all, since it is an overkill both
complexity and feature wise. DTLS is designed the way it is primarily to
extend TLS to UDP. DTLS-SRTP is a bolt on of SRTP into DTLS. So we actually
got a protocol twice reused with design goals changing dramatically in the
process. The desired attribute of DTLS-SRTP is that encryption keys are not
transmitted in clear text. The rest (security handshake separated from
signaling and ICE handshake, support for data encryption schemes other then
SRTP, support for certificate validation, etc) is actually just a
liability. All of those things imply slower setup and interop problems. So,
my second proposal was not to use DTLS at all, just include the public keys
for supported key exchange protocols in the SDP and send the encrypted SRTP
private key in the ICE message. Or something similar to that. This will
definitely not interop with DTLS, but will make implementation of
encryption very simple.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Mar 2012 09:56:51 -0400

On Tue, Mar 20, 2012 at 9:48 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> this
> SCTP
> signature
We got one group of people designing browsers, another group of people
designing monitoring proxies and the third group designing WebRTC
application. For the monitoring proxy to work it would need some sort of
network protocol to communicate with the browser (similar how HTTP proxy
needs a network protocol to work with the browser). I would expect what's
needed is some sort of network based protocol to send the SDP to a proxy,
get modified SDP back and pass it to JavaScript (or take the SDP from
JavaScript, through the proxy and to the media stack). I do not think this
is up to implementer, this is typically what the standards are for.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Mar 2012 10:03:46 -0400

On Tue, Mar 20, 2012 at 6:52 AM, Harald Alvestrand <[email-masked]>wrote:

> We should tell the user when we know he's exposed to risks that he usually
> isn't.
>
> verified identities (if that's what we normally support). We SHOULD give a
> warning saying "hey, since the gateway you've connected to isn't doing
> normal authentication procedures, but instead insists on exchanging keys on
> the signalling channel, you are less sure who you're talking to than usual,
> and there are more boxes that might record your call in the way, but the
> script kiddie on your hotel WLAN still can't see your packets (translation:
> legacy SDES key exchange is in use, but SRTP is still on).
>
What we actually got here has to be iconified into padlocks of different
size and degree of openness.

In case of DTLS-SRTP with verified identities we still need to inform the
user of the indentity of the person they are communicating with. It has to
come from the browser, so that it can be presented with some degree of
trust. Since we do not trust web server or the javascript app, we should be
asking for user consent to get access to microphone and camera for each
call anyway. When asking for this consent, we should be either telling the
identity of the remote party or give a warning that remote party is unknown.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 20 Mar 2012 15:16:11 +0100

2012/3/20 Roman Shpount <[email-masked]>:
> SRTP, support for certificate validation, etc) is actually just a liability.
> All of those things imply slower setup and interop problems. So, my second
> proposal was not to use DTLS at all, just include the public keys for
> supported key exchange protocols in the SDP and send the encrypted SRTP
> definitely not interop with DTLS, but will make implementation of encryption
> very simple.

So that proposal would modify even ICE protocol, am I right? Too much
dramatic IMHO :)

Ok, given the fact that DTLS is still an utopia (all the people know
about it but it seems that nobody has seen it in action), why not to
leave it for a future version of WebRTC and go now with SDES +
encrypted signaling path? In this way:

- We get interoperability with other technologies *already*
implementing SDES+SRTP (so ***tested***).

- DTLS can be added once it's mature/tested/widely-implemented and we
can learn from other implementations (what do they implement, interop
problems, bugs...?).

- Adding DTLS later to WebRTC does not break nothing since its usage
would be still negotiable during the session initiation.

Yes, I do know that SDES+SRTP is not the best solution, but I've never
seen a scenario in which all the cool and fantastic features of DTLS
are required. Given the comments about DTLS in this long thread it
seems that choosing DTLS would be a risk (WebRTC would become a DTLS
beta-tester...).

Regards.

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

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 20 Mar 2012 14:24:21 +0000

Adding one another issue faced in SRTP-DTLS implementation (http://www.ietf.org/mail-archive/web/siprec/current/msg03199.html).

Including Leon in this mail thread for more info. 

Thanks
Partha 

>Of Iñaki Baz Castillo
>Sent: Tuesday, March 20, 2012 7:46 PM
>To: Roman Shpount
>Cc: [email-masked]
>> The other proposal was not to use DTLS at all, since it is an overkill
>> both complexity and feature wise. DTLS is designed the way it is
>> primarily to extend TLS to UDP. DTLS-SRTP is a bolt on of SRTP into
>> DTLS. So we actually got a protocol twice reused with design goals
>> changing dramatically in the process. The desired attribute of
>> DTLS-SRTP is that encryption keys are not transmitted in clear text.
>> The rest (security handshake separated from signaling and ICE
>> handshake, support for data encryption schemes other then SRTP,
>support for certificate validation, etc) is actually just a liability.
>> All of those things imply slower setup and interop problems. So, my
>> second proposal was not to use DTLS at all, just include the public
>> keys for supported key exchange protocols in the SDP and send the
>> encrypted SRTP private key in the ICE message. Or something similar to
>> that. This will definitely not interop with DTLS, but will make
>> implementation of encryption very simple.
>
>leave it for a future version of WebRTC and go now with SDES + encrypted
>signaling path? In this way:
>
>- We get interoperability with other technologies *already* implementing
>SDES+SRTP (so ***tested***).
>
>seen a scenario in which all the cool and fantastic features of DTLS are
>required. Given the comments about DTLS in this long thread it seems
>that choosing DTLS would be a risk (WebRTC would become a DTLS beta-
>tester...).
>
>
>Regards.
>
>--
>Iñaki Baz Castillo
><[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Mar 2012 08:01:43 -0700

On Tue, Mar 20, 2012 at 7:16 AM, Iñaki Baz Castillo <[email-masked]> wrote:
> about it but it seems that nobody has seen it in action),

This is not true for DTLS in general. It's been in stacks for
a while now and is widely used in VPNs.

There certainly is rather less use of DTLS-SRTP, but it isn't unknown
either, as I believe Cullen has mentioned on the list before.

-Ekr

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 20 Mar 2012 16:39:56 +0100

On 03/20/2012 02:40 PM, Roman Shpount wrote:
> Once again, I understand how this helps in case of HTTPS, but how 
> would this help in case of WebRTC? Media description is carried in 
> some sort of application defined protocol (can even be transmitted 
> over an encrypted SCTP data channel or encrypted in javaScript), so 
> monitoring proxy cannot reliably modify it. I understand how it can be 
> allowed to fake the signature on modified SDP by inserting a 
> certificate in the browser, but how would the proxy get to the SDP in 
> the first place?

"this" = inserting a trust root in the browser?

Once you trust the root I inserted, I can intercept all your HTTPS 
connections, and thus I can replace all the Javascript you think you are 
loading from your trusted provider with Javascript of my choice.

Once your browser is running my Javascript, I can do anything the 
original application could - with the privilleges you granted to that 
application.

I think that's more or less "game over" when it comes to security.

> _____________
> Roman Shpount
>
>
> On Tue, Mar 20, 2012 at 6:41 AM, Harald Alvestrand 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>     assumed it would come provisioned with anchors,  or would allow
>>     anchor provision through some different channel.)
>>
>     Igor,
>
>     "Owning" your computer will achieve this goal both in its
>     corporate meaning and in its hacker meaning.
>
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 20 Mar 2012 11:41:41 -0400

+1

Igor

On 3/20/2012 6:52 AM, Harald Alvestrand wrote:
> Thus - we should not give any indication that we're using DTLS-SRTP 
> with verified identities (if that's what we normally support). We 
> SHOULD give a warning saying "hey, since the gateway you've connected 
> to isn't doing normal authentication procedures, but instead insists 
> on exchanging keys on the signalling channel, you are less sure who 
> you're talking to than usual, and there are more boxes that might 
> record your call in the way, but the script kiddie on your hotel WLAN 
> still can't see your packets (translation: legacy SDES key exchange is 
> in use, but SRTP is still on).
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Mar 2012 12:10:18 -0400

On Tue, Mar 20, 2012 at 11:39 AM, Harald Alvestrand <[email-masked]>wrote:

> Once your browser is running my Javascript, I can do anything the original
> application could - with the privilleges you granted to that application.
>
"this" is inserting the root certificate. It is a game over as far as
security is concerned, but the rest of your email completely missing my
point.

If, as an owner of a computer, you want to enable media monitoring with an
existing standard you need to know exactly how each application is
implemented. This is a solution for hacker but not the normal enterprise.
In order to have monitoring support in the enterprise environment you need
an ability to force the browser to proxy all the media through a monitoring
application without any application modification, via browser settings
alone.
_____________
Roman Shpount

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 20 Mar 2012 14:46:15 -0400

Harald,

Many thanks!  I did just what you suggested, and spent happy three hours 
figuring out what is going on.  I found something that claims to be my 
own certificate, allegedly signed by me (which I swear I have never 
done) as well as many other certificates from the authorities I never 
knew (nor could find any information about).  On top of all, I found two 
certificates that allege being issued by Microsoft, while they are 
marked as fraudulent. (So somenone is checking this stuff and takes action?)

The above report speaks for itself.

The key finding though is that the browser interface in NOT the only way 
to get the certificates in.  Anyone can put them in a directory, and 
this a big problem for the "hacker meaning."   Incidentally, this is not 
only the browser matter--same holds for the OS.

If root certificates were to be installed only through the browser 
administrative interface, I imagine the browser could send me a warning 
or even deny the installation.  I know there is a lot to think through 
on how to bootstrap this process, but I think it should  be possible to 
achieve.  But in this case it appears to me that the browser would need 
to have its own independent file system controlled only through the 
administrative interface.

It also appears to me that the interface should be password-protected so 
that only the legitimate owner (including corporate) can control the 
installation of root certificates. If the hacker who does not know the 
administrative password just got  access to my computer (say, via JS), 
there is no way for this hacker to  install the certificate.

I know that this issue takes off on a tangent from the RTCWeb 
discussion, so I don't want to start that. But I wanted to acknowledge 
your message and thank you for responding.  Maybe we could talk about 
this with you, Hui-Lan, and Eric off-line.

Igor

---

From: "Jim Barnett" <[email-masked]>
Date: Wed, 21 Mar 2012 06:47:37 -0700

One way to look at this case would be to say that it's the server at the
boundary of www.travel.co that is the RTCWeb endpoint,  _not_ the agent
desktop. The boundary server is acting as an RTCWeb-to-corporate network
gateway, and systems inside the corporate network are not affected.
Callers see themselves as connected to www.travel.co, rather than having
a direct RTCWeb-all-the-way connection to the agent.  I'm pretty sure
that call centers would like to do things this way since it doesn't
require any changes to their corporate infrastructure. (They can
add/upgrade the gateway without changing their recording systems or
agent desktops, etc.)

I don't see anything like this in the use case document.  Is this a use
case we want to support?  

- Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hutton, Andrew
Sent: Tuesday, March 20, 2012 6:07 AM
To: Hadriel Kaplan; Ravindran, Parthasarathi
Cc: [email-masked]
Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris

Hi,

In addition to wanting to know that you are connected to "www.travel.co"
or "www.mybank.co" you as a consumer and the company really want/need
the media to be recorded by the companies system for your own
protection. This is going to involve some kind of MITM or as we call it
in SIPREC a Session Recording Client (SRC) to be able to intercept the
media and route it to a Session Recording Server (SRS). 

The agent's desktop device could act as the SRC but more likely it will
be some kind of B2BUA that does this.  

In these scenario's you as a consumer using this service really want the
media to be secure at least as far as reaching the bank but after that
like any existing web based system you have to trust the bank with your
data this is no different whether that data is speech or text that you
entered on a web page.

The recording system should be able to work with DTLS-SRTP but it will
most likely act as a MITM so will change the DTLS fingerprint. I don't
see that as a problem.

Regards
Andy

> And, it should be noted, they *want* it that way.  They don't 
> generally want you to know which agent picked up the call, or that the

> call got transferred from an IVR to a specific agent, or got put in a 
> queue with elevator-music announcement server, or any of that.  You
"called"

> became the key-exchange transport for the SRTP key.  Since they 
> already proved they own the cert for www.travel.co, having them claim 
> to be www.travel.co shouldn't require yet more verification.
> 
> -hadriel
> 
> 
> of call center/travel site is agent or SBC. SBC can perform MITM 
> attack easily as extending SDES-SRTP to DTLS-SRTP for call center site

> is feasible.

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 21 Mar 2012 13:51:07 +0000

It will be good to add this CallCenter WebRTC usecase.

Thanks
Partha

>From: Jim Barnett [mailto:[email-masked]]
>Sent: Wednesday, March 21, 2012 7:18 PM
>To: Hutton, Andrew; Hadriel Kaplan; Ravindran, Parthasarathi
>Cc: [email-masked]
>Subject: RE: [rtcweb] Resolving RTP/SDES question in Paris
>

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 21 Mar 2012 10:58:11 -0400

+1

Indeed, this is the only way call centers could work.

Igor

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 22 Mar 2012 10:11:34 +0100

On 03/20/2012 05:10 PM, Roman Shpount wrote:
>
> On Tue, Mar 20, 2012 at 11:39 AM, Harald Alvestrand 
>>     would this help in case of WebRTC? Media description is carried
>>     in some sort of application defined protocol (can even be
>>     transmitted over an encrypted SCTP data channel or encrypted in
>>     javaScript), so monitoring proxy cannot reliably modify it. I
>>     understand how it can be allowed to fake the signature on
>>     modified SDP by inserting a certificate in the browser, but how
>>     would the proxy get to the SDP in the first place?
>
>     connections, and thus I can replace all the Javascript you think
>     you are loading from your trusted provider with Javascript of my
>     choice.
>
>     original application could - with the privilleges you granted to
>     that application.
>
> security is concerned, but the rest of your email completely missing 
> my point.
>
> If, as an owner of a computer, you want to enable media monitoring 
> with an existing standard you need to know exactly how each 
> application is implemented. This is a solution for hacker but not the 
> normal enterprise. In order to have monitoring support in the 
> enterprise environment you need an ability to force the browser to 
> proxy all the media through a monitoring application without any 
> application modification, via browser settings alone.

OK, you're worried about supporting the interceptor, not about 
preventing the interception... right?

My gut feeling is that the legitimate interceptor has to be able to say 
"only these apps are used for business purposes" - for those, he should 
be able to know how to do it.

I don't think it's possible even in theory to intercept all possible 
applications, even with your own root-cert in the user's browser. It's 
probably even possible to prove it by showing that it's equivalent to 
solving the halting problem.

So I guess administrators who have the need just have to say "these 
applications and no other".

                   Harald

---

From: Roman Shpount <[email-masked]>
Date: Thu, 22 Mar 2012 10:18:56 -0400

On Thu, Mar 22, 2012 at 5:11 AM, Harald Alvestrand <[email-masked]>wrote:

> **
> OK, you're worried about supporting the interceptor, not about preventing
> the interception... right?
>
> "only these apps are used for business purposes" - for those, he should be
> able to know how to do it.
>
Yes, I was worried about supporting the interceptor. This is all related to
my question of support of WebRTC applications in military, prisons, or
financial organizations. I think WebRTC would be completely disabled in
such locations unless web browser can be configured to confirm to some sort
of communications and monitoring policy. I do not think enabling only
certain applications is a sustainable solution, since application can only
be enabled based on its URL, but this in no way implies that the actual
protocol used for signaling exchange by this application will stay the
same. In the best case this will result in tens of specialized monitoring
rules that will need to be maintained. In the worst case, WebRTC would be
simply disabled. At this point the only workable solution that I see is
some sort of media proxy protocol.
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Mar 2012 08:33:31 -0700

On 22 March 2012 07:18, Roman Shpount <[email-masked]> wrote:
> Yes, I was worried about supporting the interceptor.

Please see: http://tools.ietf.org/html/rfc2804

---

From: Roman Shpount <[email-masked]>
Date: Thu, 22 Mar 2012 11:39:42 -0400

> Please see: http://tools.ietf.org/html/rfc2804

And I did see it. I suggest you do the same. I am not talking about
providing a back door into the system to allow wiretapping. I am talking
about a user voluntarily enabling network based recording of its own WebRTC
traffic. So, if I am an enterprise, and I own the computer, I should be
able to enforce a recording and communications policy on it. Enterprise can
do it now with HTTP/HTTPS, why not WebRTC?
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Mar 2012 08:55:29 -0700

On 22 March 2012 08:39, Roman Shpount <[email-masked]> wrote:
> So, if I am an enterprise, and I own the computer, I should be able
> to enforce a recording and communications policy on it. Enterprise can do it
> now with HTTP/HTTPS, why not WebRTC?

If you can install trust anchors, what more do you need?  A set of instructions?

---

From: Roman Shpount <[email-masked]>
Date: Thu, 22 Mar 2012 12:13:33 -0400

> If you can install trust anchors, what more do you need?  A set of

Ok, repeating my previous email:

If, as an owner of a computer, you want to enable media monitoring with an
existing standard you need to know exactly how each application is
implemented. This is a solution for hacker but not the normal enterprise.
In order to have monitoring support in the enterprise environment you need
an ability to force the browser to proxy all the media through a monitoring
application without any application modification, via browser settings
alone. For the monitoring proxy to work it would need some sort of network
protocol to communicate with the browser (similar how HTTP proxy needs a
network protocol to work with the browser). I would expect what's needed is
some sort of network based protocol to send the SDP to a proxy, get
modified SDP back and pass it to JavaScript (or take the SDP from
JavaScript, through the proxy and to the media stack).
_____________
Roman Shpount

---

From: Ted Hardie <[email-masked]>
Date: Thu, 22 Mar 2012 09:24:53 -0700

On Thu, Mar 22, 2012 at 9:13 AM, Roman Shpount <[email-masked]> wrote:
> implemented.

Given that we are talking about downloadable applications, this is
going to require some doing.  You're not going to know how each
application is implemented without vetting them in some way, which
seems to result in the whitelisting exercise that Harald pointed at
earlier.

>This is a solution for hacker but not the normal enterprise. In
> order to have monitoring support in the enterprise environment you need an
> ability to force the browser to proxy all the media through a monitoring

But you are not suggesting, I hope, that all browsers must have such a
setting, and clearly we would not suggest that it must always be on.
In the environment you describe you're basically going to have to have
both a trust anchor that allows you to man-in-the-middle all traffic
and a network configuration that makes the path through the
man-in-the-middle the most effective one.  Neither of those is within
the charter of this working group, in my personal opinion.  If you
would like me to caucus with the other chairs to see whether it is our
opinion with our hats on, please let me know.

regards,

Ted Hardie

---

From: Roman Shpount <[email-masked]>
Date: Thu, 22 Mar 2012 12:36:58 -0400

> opinion with our hats on, please let me know.
What I am suggesting is that there is a need for some sort of network
protocol to enable an external network element to monitor/modify SDP media
descriptions being passed to and from WebRTC. I would assume that
implementation and use of this protocol would be optional to a web browser
(similar how implementation and use of a SOCKS HTTP proxy is optional to a
web browser). In a sense, this should not be any different then any of the
HTTP proxy protocols. I do agree that the whole trust anchor issue is
outside of the group charter, especially since it is already supported and
implemented by the web browsers, but I would like to ask the chairs to see
if media proxy protocol actually falls under the WebRTC charter.

Thank You,
_____________
Roman Shpount

---

From: Ted Hardie <[email-masked]>
Date: Thu, 22 Mar 2012 10:30:14 -0700

On Thu, Mar 22, 2012 at 9:36 AM, Roman Shpount <[email-masked]> wrote:

> I do agree that the whole trust anchor issue is

Okay, what language in the current charter do you see as  covering
this activity?

regards,

Ted Hardie

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 22 Mar 2012 15:44:29 -0700

> Behalf Of Roman Shpount
> Sent: Thursday, March 22, 2012 7:19 AM
> To: Harald Alvestrand
> Cc: [email-masked]
...
> Yes, I was worried about supporting the interceptor. This is all
> related to my question of support of WebRTC applications in military,
> prisons, or financial organizations. I think WebRTC would be completely
> disabled in such locations unless web browser can be configured to
> confirm to some sort of communications and monitoring policy. I do not
> think enabling only certain applications is a sustainable solution,
> since application can only be enabled based on its URL, but this in no
> way implies that the actual protocol used for signaling exchange by
> this application will stay the same. In the best case this will result
> in tens of specialized monitoring rules that will need to be
> maintained. In the worst case, WebRTC would be simply disabled. At this
> point the only workable solution that I see is some sort of media proxy
> protocol.

The SIPREC working group, formed in March 2010, has solutions for
this problem.  The problem is not created by RTCWEB.  Disabling 
encryption is not necessary -- nor desirable.  "Jails" get brought up
in this context often, so using that same example, consider a prisoner 
at a jail communicating with their lawyer.  The prisoner needs secure 
communications with their lawyer without the risk of the 
communications being leaked to the press by anyone along the media 
path.  For details see http://tools.ietf.org/wg/siprec/

We will have a brietf presentation on SIPREC during my session
at RTCWEB, explaining how it can work with RTCWEB.

-d

---

From: Roman Shpount <[email-masked]>
Date: Thu, 22 Mar 2012 21:31:21 -0400

> Okay, what language in the current charter do you see as  covering
I would say that this activity would be covered by:

2. Define a security model that describes the security and privacy
goals and specifies the security protocol mechanisms necessary
to achieve those goals.

3. Define the solution - protocols and API requirements - for
firewall and NAT traversal.

I do consider ability to enforce the enterprise or location communications
policy on WebRTC clients to be one of the requirements for security and
privacy. I expect that unless ability to enforce such communication policy
within enterprises or other organizations is provided, WebRTC would be
simply disabled.

In practical terms, I expect that an organization that enforces a
communication policy disables routing to public internet and only allows
communications via a company controlled HTTP proxy. Such setup would
effectively prevent WebRTC from operations. What I am suggesting is to
provide a complimentary protocol for inspection and modification of WebRTC
SDP messages which would allow WebRTC enabled browser to control an
enterprise edge media proxy and would allow WebRTC media traffic to
traverse the enterprise firewall and to operate in such environment.

I do consider such functionality as installing trust anchors, SDP
resigning, media re-encoding and media recording by the edge proxy to be
implementation details and to be outside of the scope of this chapter.
_____________
Roman Shpount

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Mar 2012 04:29:04 +0000

comments inline…

> I would say that this activity would be covered by:

Did you mean to have a #1 before #2 below?  Your email was missing a #1.

> goals and specifies the security protocol mechanisms necessary

We've got that:
http://tools.ietf.org/html/draft-ietf-rtcweb-security
http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch

> firewall and NAT traversal.

We've got that, though not in one doc:
http://tools.ietf.org/html/draft-ietf-rtcweb-overview
http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements
http://tools.ietf.org/html/draft-ietf-rtcweb-jsep

> I do consider ability to enforce the enterprise or location communications policy on WebRTC clients to be one of the requirements for security and privacy.

OK, so what you're really saying is we have #2 and #3, but you don't agree they cover the needs, and you want more added to #2 (and ultimately #3), right?

> I expect that unless ability to enforce such communication policy within enterprises or other organizations is provided, WebRTC would be simply disabled. 
> In practical terms, I expect that an organization that enforces a communication policy disables routing to public internet and only allows communications via a company controlled HTTP proxy. Such setup would effectively prevent WebRTC from operations. What I am suggesting is to provide a complimentary protocol for inspection and modification of WebRTC SDP messages which would allow WebRTC enabled browser to control an enterprise edge media proxy and would allow WebRTC media traffic to traverse the enterprise firewall and to operate in such environment.

Well... if they really can't enforce their policies, then by definition they *should* disable it.  That's a feature, not a bug.  And luckily it *can* be disabled, which is also a feature of WebRTC.  

Having said that, I don't understand why you think an organization that has strict monitoring policies can't monitor and enforce WebRTC traffic, both the HTTP *and* the media/data channels.  They *can* do it.  It's just not "automagic", and not cheap.  But that's ok - I don't think we need to optimize the deployment complexity or cost structure for that model.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Mar 2012 05:39:35 +0000

On Mar 20, 2012, at 9:40 AM, Roman Shpount wrote:

> Once again, I understand how this helps in case of HTTPS, but how would this help in case of WebRTC? Media description is carried in some sort of application defined protocol (can even be transmitted over an encrypted SCTP data channel or encrypted in javaScript), so monitoring proxy cannot reliably modify it. I understand how it can be allowed to fake the signature on modified SDP by inserting a certificate in the browser, but how would the proxy get to the SDP in the first place?

I was trying to follow this thread backwards from today, to try to grok how you got to the conclusion that an organization with strict media monitoring policies wouldn't be able to do so for WebRTC.  I think the above email is where I get disconnected form the train of thought.

If, as in another email you sent, an organization such as the military or jail or whatever controls its network such that they use the whitelist model of only authorized applications allowed our of their network, and everything goes through the HTTP proxy, then the above statement of:

> Media description is carried in some sort of application defined protocol (can even be transmitted over an encrypted SCTP data channel or encrypted in javaScript), so monitoring proxy cannot reliably modify it.

… makes no sense to me.

If you were preventing unknown applications, you would not allow unknown UDP or TCP destination ports to be used to get out of the network.  The HTTP Proxy has to (1) know your web application wants to use another set of ports, and (2) has to allow it.  Ergo, there can be no "encrypted SCTP data channel" that was not previously authorized; nor would encrypting SDP-type-info in Javascript help you one iota, because you won't be able to actually use it to send media, since the HTTP proxy is not opening new ports for you to reach the Internet.

So I don't understand what the problem is.  If you run a super-tight network like that and you *do not* want WebRTC to work because you can't monitor it, then by design it won't work.  If you run a super-tight network like that and you *do* want WebRTC to work, then you either have to be willing to install custom browsers/apps, or your HTTP Proxy has to be able to see the HTTP traffic and correctly parse the Javascript-passed data and be a media b2bua.  That's a really nasty set of constraints, especially trying to grok the javascript enough to be a media b2bua, and undoubtedly means it won't work for many WebRTC websites.  But that's arguably the right thing to happen - downloading javascript is akin to downloading a new application for each website, and again by definition this is a network that only wants to allow applications it wants to allow, so that's what it gets: per-application control, and thus requires per-application knowledge/support.  Anything your proxy doesn't understand doesn't work, but again that's kinda the point of a super-tight policy.

Personally, if I were running such an org, and I don't know if it's possible, but I'd go get some form of rootkit/kernel-mod to intercept audio/video/keystrokes well below the user layer, so that you wouldn't have to worry what application was running - just intercept the audio/screen/keyboard somewhere near the drivers.  Presumably some companies make such things, for just such organizations? (sort of like the equivalent of CarrierIQ)  That way it doesn't matter whether it's WebRTC, Flash, or native apps.

-hadriel

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Fri, 23 Mar 2012 06:40:17 +0000

Even in case disabling encryption is not the desired behavior, I don't see the problem in using RTP-IPSec instead of SRTP-DTLS. I understand that web-browser has no standard way to identify whether plain IP or IPsec in Layer 3. So, it shall be configured by browser-user and it shall be considered as user consent. This approach helps in case in avoiding double encryption technically wherein IPSec is mandated. I know the argument that double encryption is not problem in the endpoint as it has huge CPU and memory resources but in case web-browser as part of access devices, it will have impact on performance. My issue is with mandating to use SRTP-DTLS in WebRTC and not with mandate to implement SRTP-DTLS.

Also, AFAIK HTTPS certificate is not free of cost. Whereever the cost matters like social welfare site, educational site and some free blogs, the tendency will be towards HTTP and user of those sites will have the consent to use RTP. 

Thanks
Partha

>Of Dan Wing
>Sent: Friday, March 23, 2012 4:14 AM
>To: 'Roman Shpount'; 'Harald Alvestrand'; 'Ted Hardie'
>Cc: [email-masked]
>> prisons, or financial organizations. I think WebRTC would be
>> completely disabled in such locations unless web browser can be
>> configured to confirm to some sort of communications and monitoring
>> policy. I do not think enabling only certain applications is a
>> sustainable solution, since application can only be enabled based on
>> its URL, but this in no way implies that the actual protocol used for
>> signaling exchange by this application will stay the same. In the best
>> case this will result in tens of specialized monitoring rules that
>> will need to be maintained. In the worst case, WebRTC would be simply
>> disabled. At this point the only workable solution that I see is some
>> sort of media proxy protocol.
>
>The SIPREC working group, formed in March 2010, has solutions for this
>problem.  The problem is not created by RTCWEB.  Disabling encryption is
>not necessary -- nor desirable.  "Jails" get brought up in this context
>often, so using that same example, consider a prisoner at a jail
>communicating with their lawyer.  The prisoner needs secure
>communications with their lawyer without the risk of the communications
>being leaked to the press by anyone along the media path.  For details
>see http://tools.ietf.org/wg/siprec/
>
>We will have a brietf presentation on SIPREC during my session at
>RTCWEB, explaining how it can work with RTCWEB.
>
>-d
>
>
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 23 Mar 2012 15:54:31 +0100

Hi Dan,

I don't think SIPREC has a solution to the particular problem that Roman is talking about and it would probably not be within scope of SIPREC to solve this even assuming that there is some SIP involved.

If the prison deployed its own RTCWeb application and restricted the prisoner to using only this application then of course there would be no problem with intercepting the media and a SIPREC type solution could be deployed with some kind of B2BUA which has access to both signaling and media initiating the media recording and of course informing the prisoner that they are being recorded.

However if the prisoner is allowed to access their lawyers RTCWeb application and download the JavaScript from there then SIPREC does not help the prison record the resulting media exchanged.

Regards
Andy 

> Behalf Of Dan Wing
> Sent: 22 March 2012 22:44
> completely

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 23 Mar 2012 08:01:57 -0700

> From: Ravindran, Parthasarathi [mailto:[email-masked]]
> Sent: Thursday, March 22, 2012 11:40 PM
> To: Dan Wing; 'Roman Shpount'; 'Harald Alvestrand'; 'Ted Hardie'
> Cc: [email-masked]
> Even in case disabling encryption is not the desired behavior, I don't
> see the problem in using RTP-IPSec instead of SRTP-DTLS.

Several.

IPsec ESP tunnel or transport mode?  With NAT-T support?  Is there
an API for applications to determine if the underlying OS provides
IPsec ESP for that flow (I know for Cisco IOS, the answer to that
API question is 'no'.  And that was my understanding in the version 
of Windows Server that we used to use for our call control system,
although of course that could have changed with Windows 7 or 8).
RTP over IPsec breaks link header compression (cRTP and ROHC),
which are used by some networks.

> I understand
> that web-browser has no standard way to identify whether plain IP or
> IPsec in Layer 3. So, it shall be configured by browser-user and it
> shall be considered as user consent. This approach helps in case in
> avoiding double encryption technically wherein IPSec is mandated. I
> know the argument that double encryption is not problem in the endpoint
> as it has huge CPU and memory resources but in case web-browser as part
> of access devices, it will have impact on performance. My issue is with
> mandating to use SRTP-DTLS in WebRTC and not with mandate to implement
> SRTP-DTLS.

'Double encryption' is done because it's the only way to achieve
security at various layers.

Let's take a simple example:  someone is using their PC at a coffee
shop or a conference, and (because the person is using a possibly-hostile
network, and the person is ostensibly working) they bring up a VPN.  All 
of the person's traffic goes into their VPN.  The person then accesses
paypal (or gmail, or hundreds of other example sites), which forces them 
to use HTTPS.  They are now "double encrypted".  

Can you see the difficulty in removing the HTTPS connection to Paypal
(or gmail, etc.).  Can you see the difficulty in the PC determining
the HTTPS connection is "good enough" and routing that outside the 
VPN -- it can't be done simply by port number or else someone could
accidentally run un-encrypted traffic on port 443.

And this person may well even be triple encryption, if the WiFi access 
point uses wireless encryption.  Taking your argument further, if we 
are running IPsec we should have a way to disable the WiFi encryption?
But the WiFi encryption is being used to protect that layer -- just
like the IPsec is used in the VPN to protect that layer and the HTTPS
to PayPal is used to protect that layer.

> Also, AFAIK HTTPS certificate is not free of cost. Whereever the cost
> matters like social welfare site, educational site and some free blogs,
> the tendency will be towards HTTP

Ok.  (Separate problem.)

> and user of those sites will have the
> consent to use RTP.

I don't see why those sites cannot use SRTP.

-d

> Behalf
> communications

---

From: Roman Shpount <[email-masked]>
Date: Fri, 23 Mar 2012 13:14:22 -0400

inline

> Did you mean to have a #1 before #2 below?  Your email was missing a #1.
No, I did not mean to have #1 before #2 and #3. I was quoting the exact
language in the chapter definition that should cover the activity related
to WebRTC specific proxy.

> http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch
These documents do not cover scenario when organization forces all the
traffic to go through HTTP proxy to enforce its communication policy.

> http://tools.ietf.org/html/draft-ietf-rtcweb-jsep
Once again, these documents do not cover scenario when organization forces
all the traffic to go through HTTP proxy. In such cases WebRTC simply will
not work. At best, we can advise such organizations to deploy their own
TURN server, but this allow all traffic to traverse into public internet,
not just webrtc related one, which might be undesirable.

> > I do consider ability to enforce the enterprise or location
> communications policy on WebRTC clients to be one of the requirements for
> security and privacy.
>
> OK, so what you're really saying is we have #2 and #3, but you don't agree
> they cover the needs, and you want more added to #2 (and ultimately #3),
> right?
>

I think we are currently missing one of the common network deployment
scenarios for web browsers, where web browsers are deployed on a network
non-routable to public internet with an HTTP proxy used to allow access to
the web. I believe that we should add capabilities necessary to support
such deployments.

> > I expect that unless ability to enforce such communication policy within
> enterprises or other organizations is provided, WebRTC would be simply
> disabled.
> Well... if they really can't enforce their policies, then by definition
> they *should* disable it.  That's a feature, not a bug.  And luckily it
> *can* be disabled, which is also a feature of WebRTC.
>
> Having said that, I don't understand why you think an organization that
> has strict monitoring policies can't monitor and enforce WebRTC traffic,
> both the HTTP *and* the media/data channels.  They *can* do it.  It's just
> not "automagic", and not cheap.  But that's ok - I don't think we need to
> optimize the deployment complexity or cost structure for that model.
>

The reason is that with custom signaling protocols implementing monitoring
or enforcing policies would be very hard. BTW, this is not only and not
primarily about recording traffic. This can be used to force all the
traffic outside of the enterprise to be DTLS-SRTP only, but still allow
DES-SRTP (or RTP if WebRTC will support it) within the enterprise network.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 23 Mar 2012 13:29:52 -0400

> security at various layers.
Probably a side note, but double encryption is often done since each
encryption layer serves completely different purposes.

In case of organizations that care about security of their communications
(such as NSA), it is not only the content of the communication, but the
fact that communication took place between certain parties is a secret. For
example, the fact that president is calling Israeli prime minister in the
middle of the night usually means that something significant is about to
happen and normally is a national secret, even if the content of such
conversation is unknown. To prevent eavesdropping on the communication
parties, some sort of VPN protocol such IPsec is used.

On the other hand, parties that are involved in the secure communication
need to confirm each others identities and ensure that only identified
parties will receive contents of the communication. This is insured by
HTTPS with SRTP in case of WebRTC, or by SIPS with SRTP in case of NSA
deployment.

Bottom line, in most cases double encryption is a required feature and not
a bug.
_____________
Roman Shpount

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 23 Mar 2012 10:35:24 -0700

> From: Hutton, Andrew [mailto:[email-masked]]
> Sent: Friday, March 23, 2012 7:55 AM
> I don't think SIPREC has a solution to the particular problem that
> Roman is talking about and it would probably not be within scope of
> SIPREC to solve this even assuming that there is some SIP involved.
> 
> If the prison deployed its own RTCWeb application and restricted the
> prisoner to using only this application then of course there would be
> no problem with intercepting the media and a SIPREC type solution could
> be deployed with some kind of B2BUA which has access to both signaling
> and media initiating the media recording and of course informing the
> prisoner that they are being recorded.

If recording by the jail is necessary, the identity provider would need
to the jail when you're in jail.  Or, if working at a company that
needs to record, that company would be your identity provider.  I 
work for Cisco, and my email address is [email-masked] -- Cisco clearly
owns my @cisco.com identity.

The identity provider can do many things.  For WEBRTC, the identity
provider can force themselves into being able to decrypt the SRTP session,
and they can prevent a session from being established if the end user 
([email-masked]) refuses to allow that decryption.

> However if the prisoner is allowed to access their lawyers RTCWeb
> application and download the JavaScript from there then SIPREC does not
> help the prison record the resulting media exchanged.

Putting RTCWEB aside for a moment, Javascript can establish a 
Diffie-Hellman exchange between a client and server.  After the DH exchange,
the prisoner can now securely communicate with their lawyer -- but has
to type and read (tomorrow, with RTCWEB, the prisoner could speak and
listen).  If the lawyer or prisoner were worried the DH exchange or the
Javascript itself might be compromised, they can use out of band 
techniques (exchanging pieces of paper) to verify the DH exchange 
and checksum the Javascript.  Javascript could also be used to operate 
a one-time-pad encryption system.  I think the problem with 'jails'
is not new to RTCWEB, and the problem exists if the problem space 
includes a prisoner with has access to a computer that can run code
obtained from outside the jail, such as from the Internet, such as
any Javascript.

If the concern is Javascript providing a stenography channel,
that problem is unsolvable.  That Javascript could, for all we know,
send SRTP with RTCWEB, or encrypted text messages without RTCWEB,
over any channel it wants -- including over DNS, for example.  
There is code available that sends IP over DNS, such as 
http://code.kryo.se/iodine)

-d

---

From: Roman Shpount <[email-masked]>
Date: Fri, 23 Mar 2012 13:45:10 -0400

On Fri, Mar 23, 2012 at 1:39 AM, Hadriel Kaplan <[email-masked]>wrote:

>
> I was trying to follow this thread backwards from today, to try to grok
> how you got to the conclusion that an organization with strict media
> monitoring policies wouldn't be able to do so for WebRTC.  I think the
> above email is where I get disconnected form the train of thought.
>
> If, as in another email you sent, an organization such as the military or
> jail or whatever controls its network such that they use the whitelist
> model of only authorized applications allowed our of their network, and
> everything goes through the HTTP proxy, then the above statement of:
>
> > Media description is carried in some sort of application defined
> protocol (can even be transmitted over an encrypted SCTP data channel or
> encrypted in javaScript), so monitoring proxy cannot reliably modify it.
>
> … makes no sense to me.
>
> If you were preventing unknown applications, you would not allow unknown
> UDP or TCP destination ports to be used to get out of the network.  The
> HTTP Proxy has to (1) know your web application wants to use another set of
> ports, and (2) has to allow it.  Ergo, there can be no "encrypted SCTP data
> channel" that was not previously authorized; nor would encrypting
> SDP-type-info in Javascript help you one iota, because you won't be able to
> actually use it to send media, since the HTTP proxy is not opening new
> ports for you to reach the Internet.
>
So I don't understand what the problem is.  If you run a super-tight
> network like that and you *do not* want WebRTC to work because you can't
> monitor it, then by design it won't work.  If you run a super-tight network
> like that and you *do* want WebRTC to work, then you either have to be
> willing to install custom browsers/apps, or your HTTP Proxy has to be able
> to see the HTTP traffic and correctly parse the Javascript-passed data and
> be a media b2bua.  That's a really nasty set of constraints, especially
> trying to grok the javascript enough to be a media b2bua, and undoubtedly
> means it won't work for many WebRTC websites.  But that's arguably the
> right thing to happen - downloading javascript is akin to downloading a new
> application for each website, and again by definition this is a network
> that only wants to allow applications it wants to allow, so that's what it
> gets: per-application control, and thus requires per-application
> knowledge/support.  Anything your proxy doesn't understand doesn't work,
> but again that's kinda the point of a super-tight policy.
>
>
My problem with all of this that as far as communication policies are
concerned, for all the practical purposes managing WebRTC becomes just a
big on/off switch. It is not practical to reverse engineer JavaScript
application to enable media proxy/ B2BUA to work transparently just by
monitoring  HTTP communications. Even if such HTTP proxy based B2BUA can be
developed, it will break after the first javascript application update. The
solution you describe is possible but is extremely brittle.

> Personally, if I were running such an org, and I don't know if it's
> possible, but I'd go get some form of rootkit/kernel-mod to intercept
> audio/video/keystrokes well below the user layer, so that you wouldn't have
> to worry what application was running - just intercept the
> audio/screen/keyboard somewhere near the drivers.  Presumably some
> companies make such things, for just such organizations? (sort of like the
> equivalent of CarrierIQ)  That way it doesn't matter whether it's WebRTC,
> Flash, or native apps.
>
>
Unfortunately this does not always work. What you are looking for is a way
to enforceme that all the devices on the organizational network either
confirms to organization communication policy or not allowed to
communicate. This also applies to other devices that are being brought to
your organization (ie lawyer laptop in prison). Organization cannot force
everybody to install a key logger to their computers that they bring in,
but they can force all the communications coming from within the
organization to go through some sort of proxy or not to be allowed to
communicate.
_____________
Roman Shpount

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 23 Mar 2012 19:39:02 +0100

On 03/23/2012 06:14 PM, Roman Shpount wrote:
> Once again, these documents do not cover scenario when organization 
> forces all the traffic to go through HTTP proxy.
Roman,
It seems to me that you are arguing that the scenarios in section 4.1 of 
the use cases document do not cover that specific case, and I think you 
are right in that; the list is:

    The following considerations are applicable to all use cases:
    o  Clients can be on IPv4-only
    o  Clients can be on IPv6-only
    o  Clients can be on dual-stack
    o  Clients can be on wideband (10s of Mbits/sec)
    o  Clients can be on narrowband (10s to 100s of Kbits/sec)
    o  Clients can be on variable-media-quality networks (wireless)
    o  Clients can be on congested networks
    o  Clients can be on firewalled networks with no UDP allowed
    o  Clients can be on networks with cone NAT
    o  Clients can be on networks with symmetric NAT

Now, there are two ways to interpret this omission:

- The WG did not think of that use case when the list was created
- The WG does not want that use case on the list because it constrains 
the solution space too much

If (re)opening this issue, I think I'd find myself in the "do not want 
that use case" camp.

             Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 23 Mar 2012 19:41:03 +0100

On 03/23/2012 06:45 PM, Roman Shpount wrote:
>
> Unfortunately this does not always work. What you are looking for is a 
> way to enforceme that all the devices on the organizational network 
> either confirms to organization communication policy or not allowed to 
> communicate. This also applies to other devices that are being brought 
> to your organization (ie lawyer laptop in prison). Organization cannot 
> force everybody to install a key logger to their computers that they 
> bring in, but they can force all the communications coming from within 
> the organization to go through some sort of proxy or not to be allowed 
> to communicate.
>

I think you are looking for http://tools.ietf.org/wg/nea/charters, not 
RTCWEB.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 24 Mar 2012 03:19:24 +0000

On Mar 23, 2012, at 1:45 PM, Roman Shpount wrote:

Unfortunately this does not always work. What you are looking for is a way to enforceme that all the devices on the organizational network either confirms to organization communication policy or not allowed to communicate. This also applies to other devices that are being brought to your organization (ie lawyer laptop in prison). Organization cannot force everybody to install a key logger to their computers that they bring in, but they can force all the communications coming from within the organization to go through some sort of proxy or not to be allowed to communicate.

But that *is* their policy, and it *is* being followed: as you said, their policy is "all the devices on the organizational network either confirms to organization communication policy or not allowed to communicate".  That is being followed, because all web communications go through the Organization's proxy, and if a lawyer comes in his/her web traffic goes through the proxy…  but the lawyer can't use it for WebRTC-created media - which is exactly matching the Organization's policy, because the lawyer's laptop must not and will not work for WebRTC communications.

I'm not trying to be pedantic or difficult here, or trying to dismiss the use-case.  I know there are many such "super-tight" networks, but I just don't see how we can reasonably accommodate their use-case in this WG.  And I'm pointing out that we really are following their policies, inasmuch as WebRTC media will fail to escape their network - I would be far more worried if we somehow bypassed their policies instead.  At least this way it's similar behavior they get for unknown/unauthorized applications, which is arguably what going to random websites and running downloaded javascript is equivalent to.

-hadriel

---

From: Roman Shpount <[email-masked]>
Date: Thu, 29 Mar 2012 02:18:28 -0400

On Fri, Mar 23, 2012 at 11:19 PM, Hadriel Kaplan <[email-masked]>wrote:

>  I'm not trying to be pedantic or difficult here, or trying to dismiss the
> use-case.  I know there are many such "super-tight" networks, but I just
> don't see how we can reasonably accommodate their use-case in this WG.  And
> I'm pointing out that we really are following their policies, inasmuch as
> WebRTC media will fail to escape their network - I would be far more
> worried if we somehow bypassed their policies instead.  At least this way
> it's similar behavior they get for unknown/unauthorized applications, which
> is arguably what going to random websites and running downloaded javascript
> is equivalent to.
>

Sorry for the late response, but enterprise policy does not have to be
WebRTC on or off. It can be video is not allowed from the enterprise
network but audio is ok. It can be that enterprise would only allow to
communicate with SDP signed by some predefined list of identity providers.
It can be that only certain amount of bandwidth can be used for WebRTC
traffic. WebRTC media communications can only be allowed with certain IP
networks. All of those policies are common with SIP and enterprise session
border controllers. Right now there is no granular control similar to the
control that you would get by running  SIP enabled firewall. I would
consider this a serious regression comparing to current SIP based
communications and would really like this addressed.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 29 Mar 2012 02:20:49 -0400

On Fri, Mar 23, 2012 at 2:39 PM, Harald Alvestrand <[email-masked]>wrote:

> the use cases document do not cover that specific case, and I think you are
> right in that; the list is:
>
> - The WG does not want that use case on the list because it constrains the
> solution space too much
>
I do not recall this use case ever being discussed on the working group, so
I would assume the current situation is due to WG not thinking about this
case when the list was created.
_____________
Roman Shpount

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 29 Mar 2012 14:00:39 +0200

On 3/29/12 8:18 AM, Roman Shpount wrote:
>
> On Fri, Mar 23, 2012 at 11:19 PM, Hadriel Kaplan <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I'm not trying to be pedantic or difficult here, or trying to
>     dismiss the use-case.  I know there are many such "super-tight"
>     networks, but I just don't see how we can reasonably accommodate
>     their use-case in this WG.  And I'm pointing out that we really are
>     following their policies, inasmuch as WebRTC media will fail to
>     escape their network - I would be far more worried if we somehow
>     bypassed their policies instead.  At least this way it's similar
>     behavior they get for unknown/unauthorized applications, which is
>     arguably what going to random websites and running downloaded
>     javascript is equivalent to.
>
>
> communicate with SDP signed by some predefined list of identity
> providers. It can be that only certain amount of bandwidth can be used
> for WebRTC traffic. WebRTC media communications can only be allowed with
> certain IP networks. All of those policies are common with SIP and
> enterprise session border controllers. Right now there is no granular
> control similar to the control that you would get by running  SIP
> enabled firewall. I would consider this a serious regression comparing
> to current SIP based communications and would really like this addressed.

This sounds like an excellent use case for host-based controls, and an 
excellent example of the limitations of network-based controls.

--Richard