Subject: [siprec] RTCWeb DTLS-SRTP , SDES, RTP etc.

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 19 Mar 2012 15:35:07 +0100

Hi All,

The RTCWeb working group are hoping to make a decision on the use of DTLS-SRTP, SDES-SRTP and plain RTP at IETF83. This could well go in the direction that RTCWeb clients only support DTLS-SRTP or at very least that DTLS-SRTP is the preferred choice.

I am interested in opinions as to whether we need to do more work in understand the implication of recording communication session that use DTLS-SRTP and if so where we should do this.

Probably http://tools.ietf.org/html/draft-eckel-siprec-rtp-rec-03 is the place to do this if we need to.

Any comments?

Regards
Andy

---

From: Leon Portman <[email-masked]>
Date: Mon, 19 Mar 2012 16:47:13 +0200

One of the issues that we have had with DTL-SRTP support in SRS in the past, was long time required to establish DTLS-SRTP session for call-based recording use case, which caused severe media clipping in the recording (seconds). Establishment of DTLS-SRTP session requires multiple messages and acknowledgement.

Regards

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hutton, Andrew
Sent: Monday, March 19, 2012 4:35 PM
To: [email-masked]
Subject: [siprec] RTCWeb DTLS-SRTP , SDES, RTP etc.

Hi All,

Any comments?

Regards
Andy

_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: Brian Rosen <[email-masked]>
Date: Mon, 19 Mar 2012 10:51:45 -0400

<as individual>
Sounds right, and that's not fixable, right?  You can't do something similar to a persistent TLS connection to avoid a per call RSA exchange.

Now, if the original call comes in DTLS SRTP, you can overlap the creation of the recording stream DTLS-SRTP, which wouldn't be a problem.  It would be a problem if the original stream came either unencrypted, or used SRTP with some other keying mechanism.

Brian

---

From: Leon Portman <[email-masked]>
Date: Mon, 19 Mar 2012 17:35:12 +0200

We tried some optimizations with buffering but it was very complex.

Theoretically, if both CS and RS need to establish DTLS-SRTP session in parallel, clipping can b minimized however what if SRS is located remotely ( central data center) and CS is local in the branch, then it will not work.

Leon

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, March 19, 2012 4:52 PM
To: Leon Portman
Cc: Hutton, Andrew; [email-masked]
Subject: Re: [siprec] RTCWeb DTLS-SRTP , SDES, RTP etc.

<as individual>

Brian

---

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

Andy,

RTCWeb DTLS-SRTP in CS decision should not impact SIPREC for the following reasons:

1) In case of SRC acts as RTP endpoint for CS and RS, DTLS-SRTP in CS or RS does not matter much
2) SIPREC does not even enforce to have the different SDES keys for CS and RS. It is perfectly fine to pass the same SDES key to RS as well as to the remote participant.
3) SIPREC CS is scoped for SIP
4) SRTP-DTLS in RS SIP dialog should be no different than normal SIP SRTP-DTLS session.

In case you wish to mention that SRTP-DTLS as one of the mechanism in recording media security, I'm fine.

Thanks
Partha 

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Leon Portman
>Sent: Monday, March 19, 2012 9:05 PM
>To: Brian Rosen
>Cc: [email-masked]
>Theoretically, if both CS and RS need to establish DTLS-SRTP session in
>parallel, clipping can b minimized however what if SRS is located
>remotely ( central data center) and CS is local in the branch, then it
>will not work.
>
>Leon
>
>Sounds right, and that's not fixable, right?  You can't do something
>similar to a persistent TLS connection to avoid a per call RSA exchange.
>
>Now, if the original call comes in DTLS SRTP, you can overlap the
>creation of the recording stream DTLS-SRTP, which wouldn't be a problem.
>It would be a problem if the original stream came either unencrypted, or
>used SRTP with some other keying mechanism.
>
>Brian
>
>> One of the issues that we have had with DTL-SRTP support in SRS in the
>past, was long time required to establish DTLS-SRTP session for call-
>based recording use case, which caused severe media clipping in the
>recording (seconds). Establishment of DTLS-SRTP session requires
>multiple messages and acknowledgement.
>>
>> Regards
>>
>> Leon
>>
>> The RTCWeb working group are hoping to make a decision on the use of
>DTLS-SRTP, SDES-SRTP and plain RTP at IETF83. This could well go in the
>direction that RTCWeb clients only support DTLS-SRTP or at very least
>that DTLS-SRTP is the preferred choice.
>>
>> I am interested in opinions as to whether we need to do more work in
>understand the implication of recording communication session that use
>DTLS-SRTP and if so where we should do this.
>>