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

[Tim Bray <[e-mail]>]

I’m pretty sure that at some point before the end of the year the IETF will
publish I-JSON (see https://datatracker.ietf.org/doc/draft-ietf-json-i-json/)
which simply specifies that there MUST NOT be dupe keys.  Depending on the
timeframe, referring to this might be a good solution.

On Fri, Sep 12, 2014 at 8:18 AM, Mike Jones <[e-mail]>
wrote:

>  Sure.  Here’s an analysis of the requirements about duplicate member
> names.
>
>
>
> There could be two very different kinds of objections to the present text:
>
> A.  People think we have the semantics for duplicate identifiers wrong.
>
> B.  People think we should explain the current semantics for duplicate
> identifiers more clearly.
>
>
>
> I sure hope that we’re dealing with B and not A.  Stephen, which is the
> nature of your critique of this text?
>
>
>
> If we’re in the realm of A, I think there are three possibilities for the
> semantics:
>
>
>
> 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).
>
>
>
> 2.  Require producers not to use duplicate members but allow consumers to
> accept inputs with duplicate member names in the manner defined in
> ECMAscript.  (This is the current choice.)
>
> Pros:  People can use all standard JSON parsers.  Producers are still
> required to produce well-formed data structures.
>
> Cons:  The requirements on producers are stricter than those on consumers.
>
>
>
> 3.  Allow both producers and consumers to use duplicate members, with
> duplicate member names handled in the manner defined in ECMAscript.
>
> Pros:  People can use ECMAscript parsers (which are more liberal than some
> JSON parsers).  The requirements on producers and consumers are the same.
>
> Cons:  Hidden content can be inserted into duplicate member names.  This
> could give attackers a way to manipulate the inputs to crypto operations.
> Strict JSON parsers (that reject inputs with duplicate members) can’t be
> used.
>
>
>
> Practically, I think were we presently are (2) is the best compromise
> between implementability, consistency, and security.  The working group put
> a lot of discussion into this, including changing from (1) to (2) and it’s
> my sense that most agree we’ve landed in the right place.  From a security
> perspective, I don’t think that (3) is a viable option.
>
>
>
> If people think that the current semantics are right but are not
> sufficiently clearly explained or motivated, I’d certainly welcome proposed
> text to clarify the explanation.
>
>
>
>                                                             -- Mike
>
>
>
> *From:* Kathleen Moriarty [mailto:[e-mail]]
> *Sent:* Friday, September 12, 2014 5:00 AM
> *To:* [e-mail]; [e-mail];
> [e-mail]; [e-mail]; Stephen
> Kent; Mike Jones
> *Subject:* JWK member names, was: [jose] SECDIR review of
> draft-ietf-jose-json-web-key-31
>
>
>
> Hi Mike,
>
>
>
> The text Steve called out below has been very problematic as you know.
>  Could you call out some options here as the last time this came up, we
> didn't resolve it.  The working group was asked for suggestions, but none
> came through.  If you could provide some options and then have the working
> group weigh in, I think that would be good.
>
>
>
> I snipped away the rest of the review and changed the subject as not to
> get in the way of the current dialog.
>
>
>
> Thanks.
>
>
>
> On Wed, Sep 10, 2014 at 8:57 PM, Mike Jones <[e-mail]>
> wrote:
>
> Hi Stephen.  Thanks for your detailed and useful review.  I’ve cc’ed the
> working group in my reply so they’re aware of the contents of your review.
> Replies are inline below…
>
>
>
> *From:* Stephen Kent [mailto:[e-mail] <[e-mail]>]
> *Sent:* Tuesday, September 02, 2014 1:09 PM
> *To:* [e-mail]; Mike Jones; [e-mail]; Moriarty,
> Kathleen
> *Subject:* SECDIR review of draft-ietf-jose-json-web-key-31
>
>
>
> [snip]
>
>
>
> This section imposes a rather wimpy constraint on parameter names:
>
>
>
>    The member names within a JWK MUST be unique; recipients MUST either
>
>    reject JWKs with duplicate member names or use a JSON parser that
>
>    returns only the lexically last duplicate member name, as specified
>
>    in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript].
>
>
>
> This text says that member names MUST be unique, but if they are not,
> that’s OK too; just use the last instance of a member with a duplicate
> name. This seems like a terrible design principle. It imposes what appears
> to be a requirement, then says how to accommodate data structures that fail
> to meet the requirement. This would seem to encourage sloppy
> implementations (for JWK generation). I’d like to see the rationale for
> this.
>
>
>
>
>
> Unfortunately, the intentional laxness in the spec in this regard is a
> reflection of the semantics of the actual JSON specifications and
> implementations.  For instance,
> http://tools.ietf.org/html/rfc7159#section-4 says:
>
>
>
>    An object whose names are all unique is interoperable in the sense
>
>    that all software implementations receiving that object will agree on
>
>    the name-value mappings.  When the names within an object are not
>
>    unique, the behavior of software that receives such an object is
>
>    unpredictable.  Many implementations report the last name/value pair
>
>    only.  Other implementations report an error or fail to parse the
>
>    object, and some implementations report all of the name/value pairs,
>
>    including duplicates.
>
>
>
> This topic has been heavily discussed by the working group, and while the
> specs used to just say that objects with duplicate member names MUST be
> rejected, working group members, including Tim Bray (the editor of the JSON
> spec), prevailed on us to weaken this so that parsers that implement the
> ECMAscript behavior of returning only the last member name may be legally
> used.  (The argument was made that there was more security downside in
> effectively requiring people to write and debug their own strict parsers
> than in using laxer, but well-supported and debugged parsers.)
>
>
>
> However, we also intentionally require that producers use only one
> instance of each member name, so that legally produced objects will never
> exercise the ambiguities that are present in real JSON parsers.  That
> seemed to be the most practical solution to the working group.
>
>
>
> [snip]
>
>                                                             Thanks again,
> Stephen,
>
>                                                             -- Mike
>
>
>
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>
>


-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)