Re: [rtcweb] Last Call: <draft-ietf-rtcweb-data-channel-12.txt> (WebRTC Data Channels) to Proposed Standard

[tim panton <[e-mail]>]

On 21 Oct 2014, at 08:35, Wyss, Felix <[e-mail]> wrote:
> 
> 
>> I disagree that role won't work if the middlebox is just forwarding
>> offers and answers - that's what every WebRTC signaling server is doing
>> today.   However, as I think you implied, you're also terminating DTLS
>> but forwarding SCTP (and media).  This a) implies packet-relay; b)
>> implicit decryption of all media at the server (NOTE this is a
>> security/privacy/MITM issue).
> 
> Yes, that's the intended use-case: The middlebox is a trusted man-in-the-middle.  In order to record and/or perform analytics on the media flowing through it, it obviously has to decrypt it.  That can only be done by terminating DTLS (and decrypting/re-encrypting SRTP.)    

If the middle box is trusted, only interested in media and known about by the application, then the application should create a separate 
direct data channel only DTLS connection between the endpoints that bypasses the middle box, with a small amount of extra application
effort we remove the need for even more random extra SDP lines. Remember these are programmable endpoints - not dumb SIP devices with fixed behaviours.

Unless the middle box is performing ‘analytics’ on the DC data too, but that isn’t the use-case you mentioned.

Tim.