On Thu, Jan 6, 2011 at 2:32 PM, Justin Uberti <juberti@google.com> wrote:
The connection is limited by the browser same-origin policy, so the application can only connect to places blessed by the application server, similar to XmlHttpRequest. We don't worry about apps making XmlHttpRequest over TLS, where there is little ability to control the data, and I think we should try to think of these transports the same way.
First, I'm not sure that everyone has the same view "of not worry" here. Second, I'm really not sure that the threat model is the same. If I have an open pipe between any two peers which can carry any traffic which fits over DTLS, the situation is a bit different from that where https is running through to a server. And the chances that someone terminates and re-originates the TLS flow seems to me to go up in some common cases if it has this characteristic. But I think the charter comment for now is that this is a major chunk of work, and that it has considerations outside those for audio and video. To me, that means it needs to be called out (either in its own documents or in a re-charter), so that it doesn't gate the base functionality. Please remember as well that just because the initiating use case for this protocol work is browser based there is no reason to presume that it will stay browser based for all time. Even in this framework a browser-initiated DTLS flow could be handed off to another "helper" app. Again, I think this is potentially a lot of work. That doesn't mean I think it is bad work; I think it means it has to be scoped appropriately. regards, Ted
The plan also is to be able to leverage DTLS to allow the creation of secure transports, which will have additional implications for DPI.
Agreed. More importantly, I think that reinforces the idea that this is not a simple add-on to audio/video functionality. As I argued in draft-hardie-mdtls-session, you are really creating a multi-flow session layer. I personally think that's a fine thing, but it is not an adjunct to a charter-it's the top-line bullet item in my view.
regards,
Ted
PS. As an aside, both Jake and I have since left Panasonic and the project mentioned in the draft cited above. I do not believe that the sponsor lab will release the code created for it at this time so the discussion I had with some folks on that in Beijing will likely need to take other paths.
Harald
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web