Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

From: Harald Alvestrand <[email-masked]>
Date: Fri, 03 May 2013 06:49:12 +0200

On 04/29/2013 03:40 PM, Ejzak, Richard P (Richard) wrote:
>
> I responded to this question earlier so didn't want to repeat myself, 
> but see now that it was either missed or otherwise not accepted.
>
> Quoting my earlier email from 4/25:
>
> "Legacy devices support more than just audio and video media.  We will 
> need to occasionally transport protocols like T.140, MSRP, BFCP, 
> and/or RTSP in some cases, and the primary options are to transport 
> them over DataChannels or WebSockets.  A network server will be needed 
> to do transport level interworking, of course.  It would be useful in 
> these cases to have an SDES option for DataChannels.  Not essential, 
> but useful.  End-to-end security is not even an issue in this case due 
> to the need for transport level interworking."
>
> After further consideration, I don't currently see a use case for 
> RTSP, but I still do for the others.  If we have a legacy endpoint 
> doing T.140 and audio, for example, it would be useful to be able to 
> multiplex the audio together with T.140/DC at the browser, and to put 
> a box in the network to adapt them as necessary for the legacy 
> endpoint (decode, demux, DC-to-RTP i/w for T.140, possibly 
> transcoding).  SDES for DC just makes this easier to do.
>

I don't get that - I must be dense.

DataChannel doesn't have a defined SDES encryption. So you're either 
talking about inventing a form of encryption that nobody's ever seen 
before, or you're tunneling SRTP packets over the data channel.

If transcoding, the format on DataChannel are not likely to be exactly 
the RTP headers on the T.140 side, so you have to decrypt and re-encrypt 
anyway in order to change the bits.

The other possibility is to take the encrypted SRTP T.140 packets and 
send them, raw, over DataChannel to the Web application and decrypt them 
there. "Only" requires SRTP key derivation, decryption and manipulation 
+ T.140 interpretation to be done in Javascript.

Seems possible to me - but do we really need to standardize anything for 
this option to be workable, or should we as a standards body just say 
"On your head be it"?

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 2 May 2013 22:36:21 -0700

Harald said: 

"I don't get that - I must be dense.

    DataChannel doesn't have a defined SDES encryption. So you're either
    talking about inventing a form of encryption that nobody's ever seen
    before, or you're tunneling SRTP packets over the data channel."
[BA] To put Harald's statement another way, SDES/SRTP is only defined for keying of SRTP as defined in RFC 3711. Not to put too fine a point on it, but UDP is not SRTP, and therefore concepts such as "SRTP cryptographic context" and ROC do not make sense without SRTP at least lurking somewhere nearby. 
While some existing implementations do send data in (S)RTP packets (and therefore could conceivably use SRTP/SDES as a key  management mechanism),  the term "data channel" used in the IETF RTCWEB WG implies SCTP over UDP, and therefore requires a key management mechanism that works for UDP transport (e.g. DTLS).  
Have we beaten this horse to death yet?