Re: [rtcweb] draft-jesup-rtcweb-data-00 posted

[Eric Rescorla <[e-mail]>]

On Tue, Oct 25, 2011 at 8:31 AM, Hadriel Kaplan <[e-mail]> wrote:
>
> On Oct 25, 2011, at 10:20 AM, Eric Rescorla wrote:
>
>> On Tue, Oct 25, 2011 at 1:02 AM, Hadriel Kaplan <[e-mail]> wrote:
>>>
>>> Req. 8: The data stream transport protocol MUST NOT encode IP addresses inside its protocol fields; doing so reveals potentially private information, and leads to failure if the address is depended upon.
>>
>> I don't really understand what this means. In general, the peer has
>> access to your IP address
>> information from ICE.
>
> From a privacy perspective: if a person uses a Web-site designed with privacy/anonymity in mind (e.g., battered-spouse forum), then the site would relay your media-plane stuff through a type of TURN server that does ICE itself both ways.  But if the SCTP layer on top of UDP encodes your local IP using one of the optional SCTP fields in RFC 4960 or 5061, then you lose that anonymity.  Since the SCTP layer is built into the Browser and not under control of the Javascript, a site can't prevent it from revealing that info.
>
> From a failure perspective: if the SCTP layer on top of UDP encodes local or remote IP addresses using an SCTP field, presumably it does so for some purpose.  Since history has shown that relying on embedded IP Addresses for anything is prone to failure due to the proliferation of NATs, double-NATs, v4-v6 NATs, etc., then we shouldn't want SCTP to rely on such being useful.  The best way to make sure it can't rely on them, is not to use any to begin with. :)
>
>=
OK. Sold.


>>> Req. 10: The data stream packet format/encoding MUST be such that it is impossible for a malicious Javascript to generate an application message crafted such that it could be interpreted as a native protocol over UDP - such as UPnP, RTP, SNMP, STUN, etc.
>>
>> I'm not sure this is really an issue the way you raise it. It's clear
>> that you shouldn't be able to
>> generate messages that appear to be STUN or RTP but that's necessary
>> for demux to work
>> right.
>
> Yes I didn't mean to imply it would be hard to satisfy the requirement, or not necessary for other reasons.  I suggested it because some people wanted to do raw UDP a while ago and this requirement's there to show we can't do raw UDP.

OK.


>
>> However, given that the other side has consented, I don't see
>> that confusion with
>> other protocols being an issue. The kind of intercepting proxies that
>> we found for
>> HTTP don't seem to be a feature of the UDP environment.
>
>
> I don't know that intercepting middleboxes don't exist for any/all random UDP-based protocol.  I wouldn't be surprised to find there are for DNS, for example.  But you're talking about for ever, not just now.  I don't have a crystal ball.  Regardless, I would expect this requirement to be achieved easily, no?

So, I was thinking no, but now that I think about it harder, the
answer is yes. :) [*]

-Ekr

[*] The technical reason here is that it's not easy for TLS < 1.1, but
it is easy for
DTLS, due to the way CBC mode is used in the different protocols.