[hybi] "fresh" and "uniformly at random":

["Arman Djusupov" <[e-mail]>]

Hello,

Reading carefully the following paragraph I was left wondering what is exactly meant by the use of "fresh" and "uniformly at random":

"When preparing a masked frame, the client MUST pick a fresh masking key uniformly at random from the set of allowed 32-bit values. The unpredictability of the masking key is essential to prevent the author of malicious applications from selecting the bytes that appear on the wire."

Could we use a term other than "fresh" and also clarify what "uniformly at random" means? This is a "MUST" section so it should be absolutely clear and proper in its wording. As it has now it seems to possibly be a bit vulnerable to being read in "uniformly at random" ways and open to a "fresh" interpretation by each implementor :)

With best regards,
Arman

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Peter Saint-Andre
> Sent: Friday, June 17, 2011 2:49 AM
> To: [e-mail]
> Subject: [hybi] -09: sending, closing, errors, extensions
> 
> More comments...
> 
> Section 6.1 states:
> 
>    5.  If the data is being sent by the client, the frame(s) MUST be
>        masked as defined in Section 4.3.
> 
> Section 6.2 states:
> 
>    Data frames received by a server from a client MUST be unmasked as
>    described in Section 4.3.
> 
> The word "unmasked" makes it sound like this contradicts the text in Section
> 6.1 -- as in, "must not be masked" as opposed to "the server shall remove
> the masking applied by the client".
> 
> In Section 7, the text about the close /reason/ makes it sound as if an
> application might choose to show UTF-8 encoded data to an end user. That
> might lead the reader to think that language tagging might be necessary.
> Is it?
> 
> In Section 8.2, there is no deterministic server behavior upon receiving data
> that is not valid UTF-8. Why? What use cases would motivate accepting such
> data instead of just closing the connection?
> 
> Section 9.1 says:
> 
>    Any extension-token used MUST either be a registered token
>    (registration TBD), or have a prefix of "x-" to indicate a private-
>    use token.
> 
> It's probably not a good idea to have "registration TBD" in a document that is
> going for IETF Last Call. :) Presumably a forward pointer to Section 11.6 would
> suffice.
> 
> Do we really want to encourage use of "x-"? See here for relevant
> considerations (I plan to submit an updated version soon):
> 
> http://tools.ietf.org/id/draft-saintandre-xdash-considered-harmful-01.txt
> 
> Peter
> 
> --
> Peter Saint-Andre
> https://stpeter.im/
> 
>