Re: [Json] The names within an object SHOULD be unique.

[Nico Williams <[e-mail]>]

On Thu, Jun 6, 2013 at 5:33 PM, Matt Miller (mamille2)
<[e-mail]> wrote:
> On Jun 6, 2013, at 4:21 PM, Nico Williams <[e-mail]>
>  wrote:
>> [...]
>
> Note that so far, the document uses the term "name", not "key".  I think the following needs to substitute "key" with "name" to be consistent.

Ah, sure.

>>   Encoders SHOULD NOT send duplicate keys.  Some encoders might not
>> be able to prevent duplicate keys.  Therefore parsers MUST be prepared
>> to handle duplicate keys.
>>
>>   Stateful parsers MUST accept [use?] only the last of any set of
>> duplicate keys.
>>
>
> I think this still needs to allow for stateful parsers that reject duplicate keys (for which there are some).

That's fair.

> Maybe:
>
> ####
>
> Stateful parsers MAY reject duplicate names. However, if duplicate names are accepted, it MUST accept only the last value of any set of duplicate names.

Sure.  I think we should define terms like "stateful parser" and
"streaming parser".

> ####
>
>>   Some parsers might not be able to detect duplicate keys, much less
>> pick only the last of them.  Here a "stateful parser" is one that
>> keeps on hand all of the values it decodes, as it decodes them.  Note
>> that accepting duplicate keys presents potential security risks.  Note
>> that sending duplicate keys risks data loss (that is, the loss of all
>> but the last of a duplicated key's values).
>>
>
> Can we describe a couple of specific security risks that are incurred?  I think one would be something like overwriting of the original value by an attacker intercepting the exchange.

I'm not concerned about MITMs and such.  I'm concerned about attacks
where we have a validator of some sorts as a filter and then a final
consumer.  The sender might send JSON that the validator accepts as
valid, that will be passed on to the final consumer, and where the
consumer will receive a different document (from it's p.o.v.) than the
validator saw.

Nico
--