Re: [hybi] Review of draft-ietf-hybi-thewebsocketprotocol-13

["Richard L. Barnes" <[e-mail]>]

>>>> While the "MAY" doesn't specify a requirement, it seems like it would be helpful to implementers in light of the exhaustion/DoS possibilities presented by huge frames and fragmentation.  I would even argue that it should be a "SHOULD".
>>>>     
>>> I am Ok with changing MAY to SHOULD.
>>>   
>> 
>> I'm assuming from your response below that you're OK with going to MUST as well?
>> 
> I don't think it makes much difference here, SHOULD is strong enough. But I can make it a MUST if you insist.

I was just thinking "MUST" because I couldn't think of an exception case.  It's up to you.


>>>> Section 10.3, "It is also necessary that once the transmission of a frame from a client has begun, the payload (application supplied data) of that frame must not be capable of being modified by the application."
>>>> This seems to further argue against the idea that giant frames are useful.
>>>>     
>>> Yes.
>>>   
>>>> They're clearly not useful for streaming (the opposite is suggested in Section 5.4, see above), since the application would have to provide all the data at once.  Section 10.3
>>>> This section should note that even given the masking constraints in this document, proxies are still vulnerable to poisoning by non-browser clients that do not perform masking.    
>> 
>> Suggested text:
>> "
>> Despite the protection provided by masking, non-compliant HTTP proxies will still be vulnerable to poisoning attacks of this type by clients and servers that do not apply masking.
>> "
>> 
> Ok.
> Note that that is not quite correct is masking is not optional for clients, but this is still under discussion.

Regardless of what this protocol does, the vulnerability will still be there, and you can still exploit it, e.g., with the code that was used in the experiment.  It's also not completely unimaginable that someone would make an implementation with configurable masking, if only to re-use framing code between client and server.


>>>> Section 10.4
>>>> Suggest making this a "SHOULD" or even "MUST".  If your implementation does not constrain these things, then it will be vulnerable to exhaustion attacks.      
>>> Ok.
>>>   
>> 
>> So you're changing this to MUST?
>> 
> Ok :-).

Ok!