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

[Glenn Maynard]

On Thu, Mar 24, 2011 at 8:25 AM, Harald Alvestrand <harald at alvestrand.no>
wrote:
>> 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.

The concern is still protecting against attacks: an attacker using the API
to attack this sort of broken software.

Remember that in all encryption methods discussed so far, packets always
look "masked" to an outside observer (except, in some cases, for a few
header bytes like a sequence number).  The difference is whether it's
possible for an active attacker to construct almost-arbitrary packet
contents: that's possible when using a predictable sequence number as a CTR
counter and no random per-packet nonce.

> I usually don't call that security, I call it resilience.

It's expensive resilience: 16 bytes of added overhead for every datagram.
 That's overhead added to every PeerConnection datagram protocol, in order
to help hide problems in something catastrophically broken and inherently
insecure.

> 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.)

The discussion hasn't changed--splitting threads just tends to fragment the
discussion.

-- 
Glenn Maynard