Re: [rtcweb] PeerConnection Data Channel

[Bernard Aboba <[e-mail]>]

> >> Section 5 in the WEBRTC spec 
> >> (http://dev.w3.org/2011/webrtc/editor/webrtc.html) discusses at 
> >> length a mechanism for transmitting and securing datagrams over the 
> >> PeerConnection transport. 
[BA] The objective here appears to be "masking" (e.g. to prevent sending of arbitrary datagrams) rather than providing a full set of security services. 
> > > At both an API and a wire level, this 
> >> mechanism is quite different from the existing mechanisms that are 
> >> used for transmission of audio and video data:> >> - The availability of the data stream is not easily known, whereas 
> >> audio/video can be negotiated and stream existence learned from the 
> >> *Stream methods/callbacks.
[BA] It looked to me that the data channel was negotiated in SDP, no?
> >> - It defines its own encryption mechanism, whereas audio/video will 
> >> use SDES-SRTP, or DTLS-SRTP

[BA] I don't believe that the objective here is to duplicate the security services in SRTP, DTLS, TLS, IPsec or any other comprehensive security framework. It's closer to the "masking" supported by WebSockets.  

> >> - This stream will show up in SDP

[BA] I believe that's what the current spec already says. 
> > Disagree. RTP semantics are inappropriate for sending data. The data 
> > should be sent using one of the two methods for muxing data that were 
> > proposed (one by me, one by cbran).

[BA] Agree that RTP semantics aren't necessarily appropriate for non media-stream data. 
> >> - For encryption, it simply uses the underlying encryption of the 
> >> session, i.e. none, SDES-SRTP, or DTLS-SRTP, as appropriate.

[BA] If the underlying semantics of RTP aren't a good fit, why would that make sense?
> > Absolutely correct. Possibly needs masking for the "none" case 
> > however... need to discuss.

[BA] Right.  That's why it's there, not to provide a generic security framework. 
> 
> Hmmm....  This (blah-SRTP for encrypting the data streams means full 
> un-encrypted RTP headers at a minimum, plus a bunch of those "RTP 
> semantics" you disagreed with above.  Unless I mis-understand how this 
> would work.
[BA] Right.  That's what trying to force RTP security on non-media data isn't appropriate.