[whatwg] Masking and threat models (Re: PeerConnection: encryption feedback)

[Harald Alvestrand]

On 03/24/11 08:44, Adam Barth wrote:
> On Wed, Mar 23, 2011 at 4:06 PM, Glenn Maynard<glenn at zewt.org>  wrote:
>> On Wed, Mar 23, 2011 at 6:25 PM, Harald Alvestrand<harald at alvestrand.no>
>> wrote:
>>> The STUN server is used to obtain your own "public" IP address, for
>>> constructing candidate lists.
>>> The STUN server is not involved in the ICE handshake.
>> The STUN server is not.  I believe the STUN *protocol* (packet format),
>> however, is.  See RFC5245 section 2.2 "Connectivity Checks".
>>
>> On Wed, Mar 23, 2011 at 6:43 PM, Ian Hickson<ian at hixie.ch>  wrote:
>>> directly. The concern is presumably about whether the TURN server, the
>>> remote peer, and the page origin can collude to cause the browser to
>>> attack the victim directly.
>>  From a *cursory* (an hour or so) examination of the ICE and STUN protocols,
>> it appears that even if the web server, STUN/TURN server(s) and a remote
>> peer are hostile, it should not be possible to convince a user's browser
>> (via its ICE agent) to send packets to an arbitrary IP and port.  It should
>> only be possible to send packets to an IP which has handshaked a port via
>> ICE.  Obviously, this needs to be confirmed by an expert in these protocols.
>>
>> *If* that's accurate, does that remove the masking requirement?  16 bytes
>> per packet is significant overhead to pay if it's not needed.
> Our experience with WebSockets indicates that masking is still
> important even when communicating between the browser and an
> attacker-controlled server.  The problem is that intermediaries
> attempt to "sniff" the protocol by looking at the bytes on the wire.
> For example, one could easily imagine an intermediary attempting to do
> "helpful" things to transiting UDP packets that look like DNS requests
> or responses.  Rather than play whack-a-mole with these possibilities,
> we're better off building a protocol that's secure by design.
OK, so you're not advocating masking in order to protect against an 
attacker, you're advocating masking in order to protect well-meaning 
intermediateware from its own bogus packet interpretations.
I usually don't call that security, I call it resilience.

I think we should keep those discussions somewhat separate, because 
stuff added to serve one purpose rarely is a good fit for the other. (I 
have a long list of things that I dislike because they are used for 
multiple purposes and serve neither function well ... starting with the 
source address of an IP packet .. but I digress.)

Or I may misunderstand the scenario you're talking about.
> On Wed, Mar 23, 2011 at 5:13 PM, Matthew Kaufman<matthew at matthew.at>  wrote:
>> On 3/23/2011 3:17 PM, Harald Alvestrand wrote:
>>> I also fail to see the requirement for the masking, given that the
>>> requirement for ICE (at least once the bug of not using passwords in ICE is
>>> fixed) protects against cross-socket attacks.
>> Also agree. The STUN connectivity check message in ICE is sufficient to
>> prove that the far end wants the data... masking to avoid proxies is a
>> non-issue for this channel.
> What makes you so confident that intermediaries aren't listening to
> (and possibly modifying) UDP packets?  The entire point of ICE is to
> trick intermediaries (e.g., home routers) into modifying their state
> in certain ways.  It seems entirely likely that the state of those
> intermediaries will further effected by subsequent UDP traffic.
We know they are. Some of them are doing totally broken things (for 
instance looking for the bit pattern corresponding to 10.0.0.1 and 
changing it to a NAT's external address without regard for context - 
which is the excuse for some of the more baroque constructs of the STUN 
protocol).

There is also rumoured to be devices that look for packet streams with 
regular 20 ms spacing, and block them in an attempt to prevent people 
from using nonapproved VoIP devices.

At some point, we have to declare that there is breakage introduced by 
other people's incompetence where we accept that failure will result a 
certain percentage of the time until those devices are replaced. I 
believe that the STUN XOR-ing of addresses (RFC 5389 section 15.2) was 
an example of going too far (we should have detected the brokenness and 
signalled it rather than routing around it; we traded a clear "doesn't 
work because of this kind of bogosity" function for a "will corrupt a 
known percentage of your traffic" function.... but I digress).
> On Wed, Mar 23, 2011 at 5:21 PM, Matthew Kaufman<matthew at matthew.at>  wrote:
>> On 3/23/2011 3:57 PM, Harald Alvestrand wrote:
>>> That seems like a risk that's not unreasonable to accept, given that we've
>>> survived having the same problem for HTTP links since day one of the Web
>>> (any web page can dupe a client into launching a TCP session to any IP:port
>>> and sending "GET /<ASCII string of their choice>" to it).
>> Agree, and this is even safer because it doesn't burn up TCP state at the
>> target.
> Your assumptions are incorrect.  HTTP has caused a long history of
> security problems in this regard.  Opening up UDP attack surface is
> bad news bears.
There's a cost to the complexity we're imposing too. I would like to get 
the facts straight and be able to think in terms of cost/benefit, rather 
than accepting blanket statements of requirement.