[RTW] dearly love packet inspection

[Ted Hardie]

On Thu, Jan 6, 2011 at 2:32 PM, Justin Uberti <juberti at 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 at alvestrand.no
>> >> http://www.alvestrand.no/mailman/listinfo/rtc-web
>> >
>> >
>
>