Re: [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31

[Stephen Kent <[e-mail]>]

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