Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]

From: Randell Jesup <[email-masked]>
Date: Tue, 01 Nov 2011 15:28:46 -0400

On 10/30/2011 5:00 PM, Timothy B. Terriberry wrote:
>> If we support SDES, the offer also contains crypto keys. Reusing crypto
>> keys for all created connections would be a huge security vulnerability.
>
> I'm starting to come to the opinion that we shouldn't support SDES. If
> we're doing it just for interop with legacy, we'd get better interop
> with fewer headaches by supporting plain RTP. We'd have a distinction
> between the two that I could actually explain to users, and less chance
> of (unnoticed) downgrade attacks.

SDES causes all sorts of privacy and security risks, so long as we 
retain the threat model of not trusting the JS or server, so unless we 
either a) relax the threat model, or b) allow SDES only in place of no 
encryption for non-rtcweb/webrtc destinations - i.e. never between 
rtcweb clients.  The downside would be a downgrade attack where the JS 
routes the call through a relay-and-copy server that acts as a legacy 
gateway.

My position is no SDES unless someone convinces me there's a need for it 
and it doesn't add important security risks/holes.  While SDES is the 
"most" common keying method currently (and least secure in most cases!), 
there are more keying mechanisms for SRTP than I can count/remember.

-- 
Randell Jesup
[email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Nov 2011 11:52:48 +0100

Hi, 

> If we support SDES, the offer also contains crypto keys. Reusing 
> crypto keys for all created connections would be a huge 
> security vulnerability.

If using the same keys for media assocaited with all early dialogs, one could, for each early dialog, send a new offer, with dialog-specific SDES keys.

Yes, it would require a new offer, which I have previously said I don't like. But, in this case, if you don't have to change the local IP parameters/candidates etc, the new offer would not trigger a ICE re-start etc.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Nov 2011 11:54:23 +0100

If using the same keys for media assocaited with all early dialogs is a security vulnerability, that is.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 2. marraskuuta 2011 12:53
> To: [email-masked]
> Subject: [rtcweb] SDES and forking [was RE: RTCWeb Forking 
> usecase [was RE: 
> draft-kaplan-rtcweb-sip-interworking-requirements-00]]
> 
> 
> Hi, 
> 
> > crypto keys for all created connections would be a huge security 
> > vulnerability.
> 
> If using the same keys for media assocaited with all early 
> dialogs, one could, for each early dialog, send a new offer, 
> with dialog-specific SDES keys.
> 
> Yes, it would require a new offer, which I have previously 
> said I don't like. But, in this case, if you don't have to 
> change the local IP parameters/candidates etc, the new offer 
> would not trigger a ICE re-start etc.
> 
> Regards,
> 
> Christer
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Ravindran Parthasarathi <[email-masked]>
Date: Wed, 2 Nov 2011 23:55:10 +0000

Harald,

Thanks for your clarification. Some of the usecase which comes immediately to my mind for media forking are as follows:

1) Whisper call scenario:  Telemarketing Agent makes the call to the customer and the same call is forked to Supervisor for support/monitoring. Here, Customer will not realize that Supervisor & Agent has side conversation.

2) Remote Recording: The call is forked towards remote peer as well as recording server. This usecase is already covered in usecase document

3) Interworking SIP parallel forking with RTCWeb client: 

Please let me know your opinion on addition of this usecase now.

Thanks
Partha
>From: Harald Alvestrand [mailto:[email-masked]]
>Sent: Monday, October 31, 2011 9:30 PM
>To: Ravindran Parthasarathi
>Cc: <[email-masked]>
>Subject: Re: New usecase & requirement for media forking in browser
>
>On 10/31/2011 06:23 AM, Ravindran Parthasarathi wrote:
>> Usecase:  Media forking in browser
>>
>> Description: User forks local stream/stream components to multiple
>peers simultaneously and able to receive multiple streams from multiple
>peers.
>Ravindran,
>
>I see this as an implementation description, and not an use case.
>
>Could you rephrase this in terms that make it clear what the user will
>be trying to do, and that this technology (forking) is the appropriate
>solution for that problem?
>
>That will also help uncover more requirements that the use case will
>imply. For instance, if the idea is that the user talks to multiple
>persons simultaneously, and they are able to hear each other without a
>direct connection to each other, there is an added requirement that the
>user be able to mix audio from local and remote sources.
>
>Thank you!
>
>      Harald Alvestrand
>
>> Functional requirement: F11, F12, (any new requirement has to be added
>?)
>>
>> API requirement:   The Web API MUST provide means for the web
>application to initiate sending/receiving of stream/stream components to
>a multiple peer simultaneously and relate each of these streams
>individually by web application.
>>
>> Having said that, I'm not very sure whether this usecase falls under
>the category of remote-recording by John.
>>
>> Hadriel,
>>
>> Thanks for the clarification on the current status and practical
>usecases.
>>
>> Thanks
>> Partha
>>
>>
>>> From: Hadriel Kaplan [mailto:[email-masked]]
>>> Sent: Saturday, October 29, 2011 1:58 AM
>>> To: Ravindran Parthasarathi
>>> Cc: Harald Alvestrand; Iñaki Baz Castillo;<[email-masked]>
>>> Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE:draft-kaplan-
>>> rtcweb-sip-interworking-requirements-00]
>>>
>>>
>>> We've debated serial and parallel forking a number of times but I
>don't
>>> know if there's been consensus.
>>>
>>> But your email is really two different questions/topics:
>>> 1) Is there a use-case for forking within WebRTC?
>>> 2) Does supporting SIP forking mean the Browser has to handle the
>>> SDP/media behavior of it, vs. the Web-server/Interworking-function
>>> handling it?
>>>
>>> For the first question, I can certainly envision a Web-app wanting to
>>> let Alice press a single button on her Browser and end up
>communicating
>>> with Bob no matter where he may be, or letting her single button-
>press
>>> end up communicating with Bob first and then Charlie, or letting her
>>> single button-press end up communicating with Bob and Charlie at the
>>> same time.  But I think such things can be accomplished through
>clever
>>> Web-app code without needing the Browser to be aware it's a forked
>>> ROAP/SDP scenario.
>>> [Note: though this may depend on what W3C decides the user-consent UI
>>> model is relative to PeerConnections, MediaStreams and ROAP]
>>>
>>> With regards to the second question, there was a long email thread on
>>> this which started here I think:
>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg01354.html
>>>
>>> -hadriel
>>>
>>>
>>> On Oct 28, 2011, at 3:14 PM, Ravindran Parthasarathi wrote:
>>>
>>>> Harald,
>>>>
>>>> Thanks for the clarification. "Fedex IVR" usecase is under browser
>to
>>> GW/server section (sec 4.3) which is a SIP based forking requirement.
>If
>>> you look at carefully, "Fedex IVR non-final response" scenario could
>>> have be achieved cleanly using two separate offer/answer exchange&
>two
>>> final responses (INVITE/200/ACK, RE-INVITE/200/ACK) :
>>>> 1) customer - fedex IVR offer/answer exchange
>>>> 2) fedex agent - Customer offer/answer exchange
>>>>
>>>> but it may be avoided in legacy for billing reasons which should not
>>> be major concern for RTCWeb. In case of SIP forking, it is assumed
>that
>>> 2nd answer override the 1st answer in the media plane.
>>>> As I mentioned earlier, SIP (serial) forking requirement shall be
>met
>>> by gateway signaling and no extra requirement for browser. Also,
>>> switching media stream from one responder to other responder in Fedex
>>> IVR usecase is not so easy because of legacy media handling (ICE,
>RTCP)
>>> differences as mentioned in draft-kaplan-rtcweb-sip-interworking-
>>> requirements-00.
>>>> ISTM, we don't have RTCWeb specific forking usecase till now.
>>>>
>>>> Thanks
>>>> Partha
>>>>
>>>>> From: Harald Alvestrand [mailto:[email-masked]]
>>>>> Sent: Friday, October 28, 2011 11:58 PM
>>>>> To: Ravindran Parthasarathi
>>>>> Cc: Iñaki Baz Castillo; [email-masked]; Hadriel Kaplan
>>>>> Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-
>>>>> rtcweb-sip-interworking-requirements-00]
>>>>>
>>>>> On 10/28/2011 10:56 AM, Ravindran Parthasarathi wrote:
>>>>>> By looking at draft-ietf-rtcweb-use-cases-and-requirements-06, I
>>> could
>>>>> not see any specific requirement for RTCWeb forking. In case SIP
>>> forking
>>>>> is the only requirement for RTCWeb and also, RTCWeb does not have
>any
>>>>> specific forking requirement, then the gateway between RTCWeb&
>SIP
>>>>> shall take care of the functionality. I'm asking this question to
>get
>>>>> the clarity on whether SIP forking feature has to impact RTCWeb
>>> client
>>>>> requirement or not.
>>>>> I believe the "Fedex IVR" case was specifically intended to surface
>>> the
>>>>> requirement for "non-final responses" (switching a media stream
>from
>>> the
>>>>> initial responder to a next responder).
>>>>> That's one form of forking ("serial fork"?)
>>>>>
>>>>> I haven't understood forking to be a requirement in any other use
>>> case.
>>

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 03 Nov 2011 11:37:25 +0100

On 11/03/2011 12:55 AM, Ravindran Parthasarathi wrote:
> 1) Whisper call scenario:  Telemarketing Agent makes the call to the customer and the same call is forked to Supervisor for support/monitoring. Here, Customer will not realize that Supervisor&  Agent has side conversation.
This does not need forking. The caller (the agent) is the one setting up 
2 connections.
He will also have to relay media from the customer to the supervisor.
> 2) Remote Recording: The call is forked towards remote peer as well as recording server. This usecase is already covered in usecase document
Again, this does not need forking. The client creating 2 connections is 
the one deciding to do so.
> 3) Interworking SIP parallel forking with RTCWeb client:
"Because SIP does it" is not an use case.
> Please let me know your opinion on addition of this usecase now.
I still do not see an use case from this description.
>> Cc:<[email-masked]>
>> Subject: Re: New usecase&  requirement for media forking in browser
>>

---

From: Ravindran Parthasarathi <[email-masked]>
Date: Thu, 3 Nov 2011 11:56:00 +0000

Harald,

Please read inline.

Thanks
Partha

>Sent: Thursday, November 03, 2011 4:07 PM
>> Thanks for your clarification. Some of the usecase which comes
>immediately to my mind for media forking are as follows:
>>
>> 1) Whisper call scenario:  Telemarketing Agent makes the call to the
>customer and the same call is forked to Supervisor for
>support/monitoring. Here, Customer will not realize that Supervisor&
>Agent has side conversation.
>> 2) Remote Recording: The call is forked towards remote peer as well as
>recording server. This usecase is already covered in usecase document

<partha> I'll take this usecase because it is very common usecase. Client (browser) is not required to create two connection in this scenario if recording request is going as metadata and WebRTC Server forks the request to remote peer and recorder. Please note that client is not required to know the recorder destination till get the answer. </partha>

>"Because SIP does it" is not an use case.
<partha> Agree with you as RTCWeb client is not the only way to solve this interworking usecase. Interworking itself could be the usecase for RTCWeb but it is not as we interested in Freedom world. The point to be noted is that SIP parallel forking (media) infrastructure helps for the above two usecases as well. </partha>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 07 Nov 2011 10:01:48 +0100

On 11/03/2011 12:56 PM, Ravindran Parthasarathi wrote:
> <partha>  I'll take this usecase because it is very common usecase. Client (browser) is not required to create two connection in this scenario if recording request is going as metadata and WebRTC Server forks the request to remote peer and recorder. Please note that client is not required to know the recorder destination till get the answer.</partha>
Partha,

thanks for the details. What do you base your assertion that this is a 
"very common usecase" on?
(In previous discussions on recording, when people argued for a solution 
with media relaying in the client, people have variously argued that 
this should not be supported at all.)

In the scenario you sketch, the recording device will also fail to 
capture media from the destination, so I assume that the scenario you 
suggest is just part of the scenaroi.