Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates

[Sean DuBois <[e-mail]>]

On Tue, Nov 12, 2019 at 05:09:57PM +0100, Iñaki Baz Castillo wrote:
> On Mon, 11 Nov 2019 at 10:04, Sean DuBois <[e-mail]> wrote:
>
> > Have you thought about/explored encrypting the entire SessionDescription?
>
> We can already use TLS (HTTPS or WSS) to exchange SDPs (or
> "parameters" that the receiver will use to build a "remote SDP"). We
> don't need yet another encryption layer to transmit a "blob" /
> "string" between endpoints.
>
>
I want to also solve these issues.

* Creating a PeerConnection just so that it can fingerprint the user
* Having to trust the signaling server. It would be nice if I could use
  a 'unsecured' signaling server and not worry about a MITM.

https://saltyrtc.org/pages/why-saltyrtc.html convinced me this matters.

> > There might be some issues I am not aware of, but it would give us some
> > other nice things!
> >
> > * No more SDP munging (or at least make it harder)
> >    - People shoot themselves in the foot constantly by editing things
>
> We don't do it for fun.
>
> >    - Will push people to communicate API needs more, instead of more hacks
>
> Breaking the existing ability (even if hacky) to set stereo, inband
> FEC, DTX, etc. for OPUS transmission by making it impossible does not
> seem a good idea. Yes, a better and real API is needed, but that does
> not justify breaking the only way we have to do it nowadays.
>
I would love for these APIs to exist. I don't know how to make it happen
though.

I believe the existence of SDP munging is causing these APIs to not
exist. There isn't enough pressure because these things can be
accomplished (and only if you know enough).

Currently The next generation of WebRTC developers is going to have to
re-discover all these hacks. Also since they aren't standardized they
could just go away, and no one is officially 'on the hook' to make sure
they exist.
>
>
>
> --
> Iñaki Baz Castillo
> <[e-mail]>