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 17:48 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 A263B1A802C for <secdir@ietfa.amsl.com>; Fri, 12 Sep 2014 10:48:48 -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=ham
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 vfrSBx9yqMq6 for <secdir@ietfa.amsl.com>; Fri, 12 Sep 2014 10:48:45 -0700 (PDT)
Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C10D1A6F66 for <secdir@ietf.org>; Fri, 12 Sep 2014 10:48:42 -0700 (PDT)
Received: by mail-vc0-f178.google.com with SMTP id hy4so1063797vcb.9 for <secdir@ietf.org>; Fri, 12 Sep 2014 10:48:41 -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=KRUzFZV0CpU6KfBQ6uljjcIkDnecTABfknW/1xUXGWo=; b=GUeiOMDKjRJ+CrDApSOHyYnHtdkQYigoJM2QG8JYEQCqd8CBqy3iND5Tn/nsiLChs3 IKE7CHjjbRUqRKA3D2o+4rZE0wTWxC2EwdPV6iP3IZdXnuKPqJBgeKtk2wxXI4k1H5FK cV28bKJTBSY0+WUJyAqy0O8zxh/sZQjps2d5K2blyVNJ0S9mdR50oTZVDdubokUqKgK5 c31lOYEdNFys/9d8rA7FnwUO+cdDTXifAStXDHllyg+PGvMbuiWacU8LlvwP0iQXy6CC j8my2rNoMJtTWZdctQm+il0JYht3zzQ+DSFxnYE+Wk24AH91dghN4FVAJ3J0f1LmlC8K H5Og==
X-Gm-Message-State: ALoCoQmjE8FoD/7nXq7WWudShzdqgyuVbtcCwIWmCNx20JgbES4Uphqs0d9/0w8Za4K4U2C5ye41
X-Received: by 10.52.38.134 with SMTP id g6mr6867708vdk.34.1410544121242; Fri, 12 Sep 2014 10:48:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.214.4 with HTTP; Fri, 12 Sep 2014 10:48:21 -0700 (PDT)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <CAHBU6isKHQcp2CkSFcoTFhN2fG6yW2EK6ypUkp0RBXk34nppjw@mail.gmail.com>
References: <CAHbuEH4Ccn2Z=8kEECzvgjmtshwsFoa-EH_NpkJPos7zirGeaQ@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> <CAHBU6itS0i-+iuS-28pZNm2ixE03OXRkQnVRO6g4=29G12sT2g@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439AEC0929@TK5EX14MBXC292.redmond.corp.microsoft.com> <CAHBU6isKHQcp2CkSFcoTFhN2fG6yW2EK6ypUkp0RBXk34nppjw@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
Date: Fri, 12 Sep 2014 10:48:21 -0700
Message-ID: <CAHBU6is=4XObnOXO2bhuJq07feSzaszip61zkU42Y56VgniUTg@mail.gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary=bcaec51d282a4981cc0502e1e54c
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/TUAOv7XYK1BKzvKPCa3r9o6o3FU
X-Mailman-Approved-At: Fri, 12 Sep 2014 12:05:30 -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 17:48:48 -0000

It also seems that the Security Considerations should call out malformed
messages, specifically including dupe keys, as an attack vector.  The best
defense against such attacks is for clients to reject malformed messages.

On Fri, Sep 12, 2014 at 10:29 AM, Tim Bray <tbray@textuality.com> wrote:

> Well, quoting from your option (2):
>
> “2.  Require producers not to use duplicate members ”
>
> Another way to express this would be to require that producers emit
> I-JSON.  This would also have benefits such as forbidding malformed
> Unicode, forbidding dependency on object member ordering, and staying
> within the bounds of IEEE double precision.  I agree that at this point in
> time, REQUIRING consumers to reject data with dupes is problematic, but as
> long as they’re allowed to do so, that means they can deploy I-JSON parsers
> when such things arrive.
>
> If the goal is to allow the use of off-the-shelf parsers, there’s really
> not much you can say about what consumers should do about dupe keys,
> because the behavior of such parsers is inconsistent in practice.
>
> In any practical programming scenario, what the recipient wants is to take
> the JSON and stuff objects into hashes or dicts or whatever so they can
> pull out fields by name.  They’d really rather avoid thinking about dealing
> with malformed messages - and I claim that any message with dupe keys is
> malformed.  The one way to be sure that consumers don’t have to deal with
> this crap is to require that producers don’t emit broken messages.  I-JSON
> messages have way less scope for breakage.
>
> On Fri, Sep 12, 2014 at 9:20 AM, Mike Jones <Michael.Jones@microsoft.com>
> wrote:
>
>>  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.  Tim, you were one of the
>> primary advocates for the position that implementers need to be able to use
>> JSON parsers as they actually exist – hence the change from (1) to (2) in
>> draft -12 in July 2013 after extensive working group discussion on the
>> topic.
>>
>>
>>
>> Unless you’ve changed your tune, I doubt that you’re actually saying that
>> we should move back to (1) now, which would mean that people using today’s
>> JSON parsers would be nonconformant?
>>
>>
>>
>> Once I-JSON is ubiquitous, I’d be fine doing bis versions of the specs to
>> tighten the requirement in a few years.  But until then, keeping the
>> requirement that producers must not use duplicate member names would mean
>> that if we do update to use I-JSON in the future, nothing would then break.
>>
>>
>>
>>                                                             -- Mike
>>
>>
>>
>> *From:* Tim Bray [mailto:tbray@textuality.com]
>> *Sent:* Friday, September 12, 2014 8:55 AM
>> *To:* Mike Jones
>> *Cc:* Kathleen Moriarty; jose@ietf.org; jose-chairs@tools.ietf.org;
>> draft-ietf-jose-json-web-key.all@tools.ietf.org; secdir@ietf.org;
>> Stephen Kent
>> *Subject:* Re: [jose] JWK member names, was: SECDIR review of
>> draft-ietf-jose-json-web-key-31
>>
>>
>>
>> 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)
>>
>
>
>
> --
> - Tim Bray (If you’d like to send me a private message, see
> https://keybase.io/timbray)
>



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