E2E Security and P2P media

[Cullen Jennings <[e-mail]>]

> On Feb 22, 2020, at 3:00 PM, Eric Rescorla <[e-mail]> wrote:
> 
> LACK OF E2E SECURITY
> Your charter specifies e2e security, but AFAICT, this is not
> provided by this specification, nor is it obvious how to enhance
> it to provide it. Indeed, it seems like there's not any support
> for a disjoint media path. You may recall that I made similar
> comments at the DISPATCH session in SIN, and I had understood
> that it was your intention to accommodate these cases, but
> I don't see anything here, which is somewhat disappointing.

This was in some version but accidentally got deleted out in editing but what I think we should do is something along the lines of following:

1.Include End-2-End encryption and authentication of the media packets in the base design. (and there would also still be Hop-bop provided by transport layer) 

2. Design it to work well if you are using MLS keying or something like it but the keying would be out of scope. 

That design would well to do things like cover the PERC WG uses cases. (but i am not advocating a solution like double - just we have one E2E that is keyed by something like MLS and a separate HbH that is keyed by TLS) 

I don’t think we should directly take on P2P media to start with due to the complexity that an ICE like protocol adds. Most the uses cases driving this work fine in the same sort of way that HTTP works without any P2P.  Much of the “P2P” SIP and WeBRTC traffic actually goes via a TURN server or other tunnel and RIPT would support that sort of relay topology as long as we had a E2E crypto. 

I do think it might be possible that we will be able to use WebRTC set up a data channel then run RIPT  over that data channel.