Re: Security concern about open range integers (was: Question about: 4.1.1 Integer representation)

If any value is too large, the connection should be torn down.
The definition of 'too large' depends utterly on details that we cannot
predict.
For many SoC or embedded implementations, this may be 4k.
For better provisioned clients, this could be gigabytes or terabytes.

This problem already exists in SPDY, and is dealt with in the venerable
tradition of deciding if the request is sane, and if not, dealing with it :)

As for speed-- for the data frames we don't use this kind of encoding-- the
overhead of a fixed encoding is small there.
For a compressor, this isn't as true-- the overhead of a fixed encoding is
much higher.
In any case, the vast majority of the time, there will be zero speed
difference since the first byte is all that is necessary to encode the
index/length.
-=R


On Sun, Oct 20, 2013 at 5:18 PM, Frédéric Kayser <f.kayser@free.fr> wrote:

> Hello,
> let me express it a bit differently "the well known and well supported
> format" is an universal integer encoding (closely related to a 7, 7, ∞
> start-step-stop code) this means it can encode any integer of unknown size
> including ridiculously large ones.
> Know how is a server supposed to react if it receives a malicious header
> that states that the next field is FF FF FF FF FF FF FF FF 7F bytes long
> (thats 2^56 + 255 if I'm not wrong)? Naive implementations will probably
> have a shock trying to decode this in a fixed size 32-bits int (add a
> couple of FF and it overruns a 64-bits int) or allocating memory for the
> field in question, others may discard it, but at which point take the cut
> between legitimate large values and malicious ones? My concern is that
> every 8+ or whatever+ is a potential memory bomb if its not capped at some
> point.
>
> My initial concern was rather a speed concern (read micro-optimization to
> speed-up decoding) concerning "the well known and well supported format"
> since a capped version of such a code could be processed faster, encoding
> is always relatively fast decoding is a bit more tricky since the bits
> recorded first are groups of 7 least significant bits whereas a
> real start-step-stop code would keep the natural bit order and would not
> require bit shifts (just byte swaps eventually).
>
> Regards
> --
> Frédéric Kayser
>
> Roberto Peon wrote:
>
> The rest of the int is in a well known and well supported format.
>
> -=R
> On Oct 18, 2013 1:03 AM, "Frédéric Kayser" <f.kayser@free.fr> wrote:
>
>> And wouldn't it be way easier and faster to record/reconstruct such
>> integers by moving all the flags (most significant bits) of each byte in
>> front of the code?
>>
>> I < 128
>> 0xxxxxxx
>> I < 16.384
>> 10xxxxxx xxxxxxxx  (compared to 1yyyyyyy 0yyyyyyy groups of 7 least
>> significant bits first)
>> I < 2.097.152
>> 110xxxxx xxxxxxxx xxxxxxxx  (compared
>> to 1yyyyyyy 1yyyyyyy 0yyyyyyy groups of 7 least significant bits first)
>> I < 268.435.456
>> 1110xxxx xxxxxxxx xxxxxxxx xxxxxxxx  (compared
>> to 1yyyyyyy 1yyyyyyy 1yyyyyyy 0yyyyyyy groups of 7 least significant bits
>> first)
>> …
>>
>> Where xxx…xxx is simply the binary representation of I
>>
>> The first part looks like unary coding and the overall form of this
>> encoding is a 7, 7, ∞ start-step-code or a base 128 Elias γ′ code, do you
>> really want to keep the universal nature of such a code or cap it?
>>
>> Regards
>> --
>> Frédéric Kayser
>>
>
>