Mike,
...
So you're advocating this alternative from the analysis, correct?
1. Require producers not use duplicate members and require consumers
to reject inputs with duplicate member names.
Pros: This is the most locked-down, consistent, and alternative.
Cons: Real JSON parsers don't all reject duplicate inputs. If we
force people to write custom parsers, this will result in exploitable
bugs (and some just won't do it and won't be conformant).
The primary reason that the working group changed from this
alternative in draft -12 in July 2013 to the present one is that it
allows JSON parsers as actually deployed and supported to be used.
The argument made then was that forcing people to write a custom
parser to reject duplicate member names is likely to create security
bugs, since insufficiently locked down parsers are a fertile area for
security vulnerabilities. It was thought that it was better to have
people using well-maintained, standard parsers and count on producers
to not emit duplicate member names in the first place. Is there some
aspect of this reasoning that doesn't seem convincing to you, Stephen?
I read the rationale. Is there a good baseline of experience showing
that JSON parsers are
not very exploitable today? We have seen problems with ASN.1 parsers,
problems that have
taken years to surface, despite extensive use of ASN.1 in both certs and
in SNMP. I suggest,
without substantiation, that bugs in ASN.1 parsers were not exploited in
the SNMP context
because there was little to gain. Use of ASN.1 for certs, where there
can be financial incentives
for exploiting flaws, motivated more analysis by attackers. If JOSE
represents an initial
step into an arena where crypto is to be applied to JSON in a widespread
fashion, it also
may represent a new motivation for attackers to try to exploit any bugs
in parsers. If so, then
the lack of identified vulnerabilities in JSON parsers so far may not be
indicative of their
security.
...
You apparently misunderstood the point of my reply to Tim. I wasn't
saying that changes aren't possible. I was saying that we want JOSE
to be usable by people now -- not just several years in the future
when parsers for a more locked-down JSON dialect may become available.
I did misunderstand your point, perhaps because you said:
"I understand that that's an ideal long-term solution, once I-JSON
parsers are common/ubiquitous, but I don't expect that to be the case
for a number of years and _*people are using JOSE now.*_"
Steve
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
