The goal here is not to defend against attackers. It's to prevent benign intermediaries from causing breakage.
The point here is that a JOSE implementation needs to get the same understanding of a JOSE object regardless of which of the multiple equivalent forms of the JSON form it gets. This is about having a well-specified protocol, for which transformations that produce equivalent JSON objects should produce equivalent JOSE objects. That is, the following process should be lossless: JOSE --stringify--> JSON --reorder-fields--> JSON --parse--> JOSE If that's not the case, then we've built a broken protocol. --Richard On Thu, Jun 27, 2013 at 7:00 PM, Mike Jones <[email protected]>wrote: > Yes – but this is only a problem for the JSON Serialization – and then, > only for fields that are not integrity protected.**** > > ** ** > > If you don’t care enough about the content of the header fields to > integrity protect them, you clearly don’t care whether an intermediary can > tamper with them. Reordering duplicate member names is the only the tip of > the iceberg of the tampering that not integrity protecting header fields > enables. The intermediary could delete them or completely rewrite them!** > ** > > ** ** > > Defending only against field reordering is like putting your finger in a > hole in the dike when the floodgates next door are already wide open. Your > field will definitely flood when the sea rises.**** > > ** ** > > -- Mike*** > * > > ** ** > > *From:* Richard Barnes [mailto:[email protected]] > *Sent:* Thursday, June 27, 2013 3:56 PM > > *To:* Mike Jones > *Cc:* John Bradley; Tim Bray; Jim Schaad; Manger, James H; [email protected]; > [email protected] > *Subject:* Re: [jose] #27: member names MUST be unique needs additional > text**** > > ** ** > > In a JSON-formatted JWS, the top-level JSON fields are not covered by the > signature (only the protected header). See the examples in my previous > mail and in John's.**** > > --Richard**** > > ** ** > > On Thu, Jun 27, 2013 at 6:51 PM, Mike Jones <[email protected]> > wrote:**** > > If an intermediary reorders the fields the signature validation will fail, > so I’m not worried about that.**** > > **** > > -- Mike*** > * > > **** > > *From:* Richard Barnes [mailto:[email protected]] > *Sent:* Thursday, June 27, 2013 3:48 PM > *To:* Mike Jones > *Cc:* John Bradley; Tim Bray; Jim Schaad; Manger, James H; [email protected]; > [email protected]**** > > > *Subject:* Re: [jose] #27: member names MUST be unique needs additional > text**** > > **** > > On Thu, Jun 27, 2013 at 12:42 PM, Mike Jones <[email protected]> > wrote:**** > > I’ve come to believe that James’ proposed language does a good job of > making security-appropriate restrictions while allowing the use of existing > parsers. It was:**** > > **** > > A creator of a JOSE message MUST NOT put duplicate names in any JSON > object in a JOSE header. To prevent attacks where a JOSE message is > interpreted as different valid messages by different recipients, each > recipient MUST either reject messages with duplicate names or accept only > the last name.**** > > **** > > I might change “or accept only the last name” to “or use a parser that > always uses the lexically last name for any duplicate member names, per > [ECMAScript]” for clarity, but the intent is the same.**** > > **** > > Would that work for people?**** > > **** > > -- Mike**** > > **** > > **** > > That's close. I don't think we can allow the "lexically last" because > elements in a JSON dictionary can be re-ordered. Suppose there a helpful > intermediary that sorts a JSON dictionary in descending alphabetical order > of values. **** > > When it gets: { "payload": "bad stuff", "payload": "good stuff", ... }*** > * > > It emits: { "payload": "good stuff", "payload": "bad stuff", ... }**** > > **** > > The only way to avoid the ambiguity is to reject objects with duplicate > keys.**** > > **** > > > I realize that this renders most JSON parsers incompatible. Implementors > will need to add a secondary check. I feel your pain. But hopefully this > pain will be temporary; the ambiguity will be fixed by the JSON WG and > ECMA, and parsers will be updated. Even in the short run, it doesn't seem > like it would be that hard to mod existing parsers to have a "strict" flag. > **** > > **** > > """**** > > A creator of a JOSE message MUST NOT put duplicate names in any JSON > object in a JOSE header. To prevent attacks where a JOSE message is > interpreted as different valid messages by different recipients, each > recipient MUST reject messages. Implementations MUST NOT select the > lexically last name, as required by [ECMAScript], since this could lead > them to select the incorrect value if an intermediary re-orders the fields > in a dictionary. If an implementation uses a JSON parser that does not > reject objects with duplicate fields, then it MUST verify that there are no > dictionaries with duplicate fields in the JSON object.**** > > """**** > > **** > > --Richard **** > > **** > > **** > > **** > > **** > > **** > > **** > > *From:* John Bradley [mailto:[email protected]] > *Sent:* Thursday, June 27, 2013 8:49 AM > *To:* Tim Bray > *Cc:* Manger, James H; Mike Jones; Jim Schaad; [email protected]; > [email protected]**** > > > *Subject:* Re: [jose] #27: member names MUST be unique needs additional > text**** > > **** > > The problem is not wanting to leave a hole for malicious signers to create > JWT that may be misinterpreted by the receiver. Accidental interop > problems from bad signers are not a big concern for me and are covered by > MUST NOT emit dups.**** > > **** > > Accepting malformed JSON as the envelope may lead to real security issues. > **** > > **** > > This may be more of an issue for the JSON encoding than the compact as > there you need to be careful the body you process for the signature is the > body that the application uses.**** > > **** > > What happens if you receive.**** > > **** > > {"protected":<integrity-protected shared header contents>",**** > > "unprotected":<non-integrity-protected shared header contents>",**** > > "payload":"<original payload contents>",**** > > "payload":"<bad payload contents inserted by attacker>"**** > > "signatures":[**** > > {"header":"<per-signature unprotected header 1 contents>",**** > > "signature":"<signature 1 contents>"},**** > > ...**** > > {"header":"<per-signature unprotected header N contents>",**** > > "signature":"<signature N contents>"}],**** > > }**** > > **** > > If the JOSE library validates on the first version of "payload" and the > application using a different JSON parser only sees the second "payload" we > have a wrapping attack similar to xmldsig.**** > > **** > > I can't off the top of my head think of what you could do in the compact > serialization that would lead to a successful attack given that the > signature is over the base64url encoded segments, that prevents attackers > from modifying the JSON while maintaining integrity.**** > > **** > > It is a real issue for the JSON serialization though.**** > > **** > > John B.**** > > **** > > On 2013-06-27, at 11:20 AM, Tim Bray <[email protected]> wrote:**** > > **** > > The approach just seems wrong. If we require that conforming > implementations MUST NOT emit dupes, then authors of receiving software can > just pick the best-performing parser with the nicest API, because they > *all* perform correctly when there are no dupes. > > Who’s going to own the responsibility for making the authoritative finding > that of the many JSON parsers in the Java ecosystem, these ones, but not > those ones, are usable in JOSE applications? And suppose one that has been > previously OK is quietly optimized on GitHub to run 30% faster and as a > side-effect silently ignores dupes? **** > > The benefit of using JSON is that there is widely deployed software to > handle it. It is a known problem that sloppy spec drafting has allowed > various kinds of problems to occur when dupe keys are received. “Doctor, it > hurts when I do this.” “So... don’t do that.”**** > > Are we also going to specify the behavior of receiving software when the > JSON has a misplaced quotation mark? A missing trailing “}”?**** > > -T**** > > **** > > **** > > On Wed, Jun 26, 2013 at 11:29 PM, Manger, James H < > [email protected]> wrote:**** > > Most JSON libraries that silently accept [sob] dupe keys at least > consistently use the last key. Allowing just that behaviour (or rejecting > dupes), while forbidding acceptance of a non-last dupe (eg first key), is > safe and allows most JSON libraries to be used. Since this accepts most > libraries I think it is practical.**** > > **** > > Hence I suggest:**** > > **** > > > A creator of a JOSE message MUST NOT put duplicate names in any JSON** > ** > > > object in a JOSE header.**** > > > To prevent attacks where a JOSE message is interpreted as different*** > * > > > valid messages by different recipients, each recipient MUST either**** > > > reject messages with duplicate names or accept only the last name.**** > > **** > > This isn’t “truly predictable” as a message with dupes might be accepted > or rejected. The crucial point is that if a message is accepted it is > predictable.**** > > **** > > --**** > > James Manger**** > > **** > > *From:* Tim Bray [mailto:[email protected]] > *Sent:* Thursday, 27 June 2013 4:16 PM > *To:* Manger, James H > *Cc:* Mike Jones; Jim Schaad; [email protected]; > [email protected]**** > > > *Subject:* Re: [jose] #27: member names MUST be unique needs additional > text**** > > **** > > **** > > Well, you have a practical problem in that most implementers will want to > use a standard JSON library, which is good practice because it will be > well-debugged, and most libraries [sob] silently take care of dupe keys and > don’t have a way to tell the client software what happened. So if you want > truly predictable behavior, you’re forcing the use of hand-constructed JSON > parsers. And that sucks, because getting good performance in JSON parsing > is surprisingly hard, with dramatic performance differences between > implementations. So you’re forcing receiving software which wants to be > conformant to use a hand-rolled parser which will probably have lousy > performance and have other bugs which in fact may compromise security more > than dupe-key tricks could. -T**** > > **** > > On Wed, Jun 26, 2013 at 10:39 PM, Manger, James H < > [email protected]> wrote:**** > > > I think it’s a nice clean minimal solution to say that producers MUST > > NOT generate dupes, end of story. I don’t think saying anything beyond > > that adds value. -T**** > > Clean and minimal that may be, but it ignores the security issue. We don't > want a malicious producer (who is so malicious they ignore a MUST) to > create JOSE messages that a JOSE-compliant security layer accepts as > "benign interpretation #1" so it passes the message on to the > JOSE-compliant backend app that acts on "nasty interpretation #2". > > -- > James Manger**** > > **** > > **** > > **** > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose**** > > **** > > ** ** >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
