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

Tim Bray <tbray@textuality.com> Fri, 12 September 2014 15:55 UTC

Return-Path: <tbray@textuality.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47D81A0382 for <secdir@ietfa.amsl.com>; Fri, 12 Sep 2014 08:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EmKOWddJh7x for <secdir@ietfa.amsl.com>; Fri, 12 Sep 2014 08:55:48 -0700 (PDT)
Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65B901A02EF for <secdir@ietf.org>; Fri, 12 Sep 2014 08:55:48 -0700 (PDT)
Received: by mail-vc0-f181.google.com with SMTP id ij19so878326vcb.40 for <secdir@ietf.org>; Fri, 12 Sep 2014 08:55:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=z3rTfKAw9o0ZH8RBKOM7K1sUcCgsDYOYQ0XTxEyO7EQ=; b=dNpWW55aEEmRwpNchJNR3LsaOehMuco4bsNZimSzbic56FV9KweJUC3mJQgSb9RlPO mENmw4kskWD0Inw2oGV0q8cr3208/6FeHPSNnULHZ4RzvUtlD+nngqR2Nea7KjVuRAx1 fpn8H22aISE5dBRlxCpJJ54YZJGYVG2KdpM4fUFkeOJ0LiEAiPBKhS6SyqaKUwYJWi+u TIdg8Treg05gkgabnaxDrmcBeZYC5KblOOMSUVidPmi1+AMXzINkpwUx5E4zipNtJbyC HmPDVZR7gA2acCk5AjmkDXO5XVLWnUu1H7PeXJ+3Vi67QR7ASuo/SC7Tq5EEw3UlexNh wqdw==
X-Gm-Message-State: ALoCoQk/t5LKwjQdmb4E0dw/2VUHt6+wAeTZIy7lv7311xleNDerPxG76qImY2PhTdGkmlc2+WqS
X-Received: by 10.220.17.145 with SMTP id s17mr2007124vca.77.1410537347312; Fri, 12 Sep 2014 08:55:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.214.4 with HTTP; Fri, 12 Sep 2014 08:55:27 -0700 (PDT)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com>
References: <CAHbuEH4Ccn2Z=8kEECzvgjmtshwsFoa-EH_NpkJPos7zirGeaQ@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com>
From: Tim Bray <tbray@textuality.com>
Date: Fri, 12 Sep 2014 08:55:27 -0700
Message-ID: <CAHBU6itS0i-+iuS-28pZNm2ixE03OXRkQnVRO6g4=29G12sT2g@mail.gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary=001a11c3bfb28784c20502e051ac
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Z3Y-132Ey7jnngsT8rAFVqrKmvM
X-Mailman-Approved-At: Fri, 12 Sep 2014 12:05:27 -0700
Cc: "jose-chairs@tools.ietf.org" <jose-chairs@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-jose-json-web-key.all@tools.ietf.org" <draft-ietf-jose-json-web-key.all@tools.ietf.org>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [secdir] [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Sep 2014 15:55:52 -0000

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 <Michael.Jones@microsoft.com>
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:kathleen.moriarty.ietf@gmail.com]
> *Sent:* Friday, September 12, 2014 5:00 AM
> *To:* jose@ietf.org; jose-chairs@tools.ietf.org;
> draft-ietf-jose-json-web-key.all@tools.ietf.org; secdir@ietf.org; 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 <Michael.Jones@microsoft.com>
> 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:kent@bbn.com <kent@bbn.com>]
> *Sent:* Tuesday, September 02, 2014 1:09 PM
> *To:* secdir@ietf.org; Mike Jones; jose-chairs@tools.ietf.org; 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
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>


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