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

The term "fresh" is a term of art in cryptography.  It means, roughly,
"not used previously."  The term "uniformly at random" means draw from
the uniform random distribution over the set of all 32-bit sequences.
Both qualifications are necessary for this purpose.

Adam

On Fri, Jun 17, 2011 at 6:32 AM, Arman Djusupov <arman@noemax.com> wrote:
> 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: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of
>> Peter Saint-Andre
>> Sent: Friday, June 17, 2011 2:49 AM
>> To: hybi@ietf.org
>> 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/
>>
>>
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>