Re: [jose] #27: member names MUST be unique needs additional text

[Richard Barnes <[e-mail]>]

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 <[e-mail]>wrote:

>  If an intermediary reorders the fields the signature validation will
> fail, so I’m not worried about that.****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* Richard Barnes [mailto:[e-mail]]
> *Sent:* Thursday, June 27, 2013 3:48 PM
> *To:* Mike Jones
> *Cc:* John Bradley; Tim Bray; Jim Schaad; Manger, James H; [e-mail];
> [e-mail]
>
> *Subject:* Re: [jose] #27: member names MUST be unique needs additional
> text****
>
> ** **
>
> On Thu, Jun 27, 2013 at 12:42 PM, Mike Jones <[e-mail]>
> 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:[e-mail]]
> *Sent:* Thursday, June 27, 2013 8:49 AM
> *To:* Tim Bray
> *Cc:* Manger, James H; Mike Jones; Jim Schaad; [e-mail];
> [e-mail]****
>
>
> *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 <[e-mail]> 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 <
> [e-mail]> 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:[e-mail]]
> *Sent:* Thursday, 27 June 2013 4:16 PM
> *To:* Manger, James H
> *Cc:* Mike Jones; Jim Schaad; [e-mail];
> [e-mail]****
>
>
> *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 <
> [e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose****
>
>  ** **
>