Double E2E encryption in case of WebRTC

[Kagami]

Hi. I read through the docs and it seems to be you are planning to support the WebRTC transport. Telehash requires encryption of all data in the stream but WebRTC already has its own end-to-end encryption (DTLS/DTLS-SRTP) so it would result in some overhead. What do you think? Should telehash has an option to disable encryption (leaving signing of the messages) in case of direct peer-to-peer WebRTC channels? Or something like that.

[dchote]

At this point I'm not 100% certain of the fate of webrtc "over" telehash. There will be a parallel media over Telehash spec sometime soon, because as you say, there is a lot of functional duplication transporting the full webrtc protocol.

[fd]

I think kagami is referring to the webrtc transport (telehash over webrtc).

Yes webrtc has its own encryption but in the context of telehash webrtc only represents a single hop. So the telehash encryption is still needed.

[dchote]

My bad. I should have clicked the link

[Kagami]

@fd I agree with you that in case of bridging we can't trust router and should always encrypt packets. But I mentioned in issue the case when peers are connected directly and transfer information between each other. Why do they need to use telehash encryption on top of WebRTC one?

[quartzjer]

@Kagami somewhere I need to make a very definitive statement about the fundamental nature of telehash, that what you're describing is by design and an ideal use case.

I feel very strongly that all traffic should always use all available transport encryption, multiples of whenever possible. The fact that WebRTC has encryption between peers, /combined/ with the telehash end-to-end encryption, should be the default and desired configuration.

There is no such thing as too much crypto overhead now or ever again.