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

Richard Barnes <rlb@ipv.sx> Thu, 18 September 2014 15:03 UTC

Return-Path: <rlb@ipv.sx>
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 C60341A045A for <secdir@ietfa.amsl.com>; Thu, 18 Sep 2014 08:03:59 -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 kYM95Ih-XeWV for <secdir@ietfa.amsl.com>; Thu, 18 Sep 2014 08:03:57 -0700 (PDT)
Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F021A0097 for <secdir@ietf.org>; Thu, 18 Sep 2014 08:03:37 -0700 (PDT)
Received: by mail-lb0-f182.google.com with SMTP id u10so1336529lbd.13 for <secdir@ietf.org>; Thu, 18 Sep 2014 08:03:35 -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:date :message-id:subject:from:to:cc:content-type; bh=5Ul9swLms5JANkfMw91BLo4pscHdxx8vlUN8yKrWK7M=; b=KPk4tn1pC1wXGBYly4XnAYwU+V/NUmMoONjc+JpvOJ/8FqrXR4WE+bG2nRRg/WwzDX qzo5YmLe6NYTJLggPtAIwKI0eoaQp6TbcQbv4+XHYCq5kZvt7OgFTjZut+aW3EsvdqVO JCdHv4vR6uj9J39CeCYF36h3ZHVXW6RPZ56whbAJTIPD4R9S6mleLBjDKZaHvRSpM2VJ 3rZrh2CJRdtnHusI9B1CXpI0Uedigl+FUaLQ8RGLurF8xiWMX7dQwrTlR26ftXLJzeQz dV2Jcv4NMkBRcKjj8VtRMUljoEg2K0uime2CrcZVRXkAPxGcHKctMR408qxWXeeNUNWc /yqA==
X-Gm-Message-State: ALoCoQncW0mOxIoZKINykZdHraYa9bc64J65/lFsW+yyMR4sZLuSpF3EnZ88dinIk089WeoLHDhI
MIME-Version: 1.0
X-Received: by 10.112.150.194 with SMTP id uk2mr112637lbb.97.1411052615317; Thu, 18 Sep 2014 08:03:35 -0700 (PDT)
Received: by 10.25.159.84 with HTTP; Thu, 18 Sep 2014 08:03:35 -0700 (PDT)
In-Reply-To: <21530.37486.670938.432565@fireball.kivinen.iki.fi>
References: <CAHbuEH4Ccn2Z=8kEECzvgjmtshwsFoa-EH_NpkJPos7zirGeaQ@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> <5416FE10.3060608@bbn.com> <CAHBU6iu3GfsLCAint3z7risZUnVW4EK0WrGVW6Dv=gvppiHSxQ@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439AECCCDD@TK5EX14MBXC292.redmond.corp.microsoft.com> <54173546.5000400@bbn.com> <CAHBU6ivb3BeEufcnJB+eSk8wgETMx+qzH3miE6Z1jtrQkXNR3w@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439AECE40B@TK5EX14MBXC292.redmond.corp.microsoft.com> <54184EBA.3010109@bbn.com> <4E1F6AAD24975D4BA5B16804296739439AED1727@TK5EX14MBXC292.redmond.corp.microsoft.com> <5418987E.1060307@bbn.com> <CFD36394-E707-4D51-9689-DD8B1FD320D5@ve7jtb.com> <54199E11.1000809@bbn.com> <CAHBU6ivJ+mQZetWDDkRjP1nB+XOCLyXatq4k9bv4y7onAgu=ug@mail.gmail.com> <21530.37486.670938.432565@fireball.kivinen.iki.fi>
Date: Thu, 18 Sep 2014 11:03:35 -0400
Message-ID: <CAL02cgQny8G9Q3CR53Kw5YUFSnkv9ejHDsrB6SWQwUFLbjBzFA@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Tero Kivinen <kivinen@iki.fi>
Content-Type: multipart/alternative; boundary=047d7b342f0ce5451b050358490b
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/FEw546TEOLebAPhN0fEkWJs1MJk
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>, Michael Jones <Michael.Jones@microsoft.com>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, Tim Bray <tbray@textuality.com>, "jose@ietf.org" <jose@ietf.org>, John Bradley <ve7jtb@ve7jtb.com>
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: Thu, 18 Sep 2014 15:04:00 -0000

We had a whole working group on JSON, which I was hoping would solve the
problem of duplicate members (by forbidding them).  That would have caused
the parser community to get more strict.

Unfortunately, that didn't happen, largely due to concern over streaming
generators/parsers that can't keep track of what keys they've seen.
Whether you agree with that or not, that's the IETF consensus in the
current JSON RFC.

The JOSE documents are not the place to solve JSON's duplicate-key
problems.  We tried to that problem and decided not to.

So we have two choices: Either deal with the limitations of the tool, or
throw it away and use another.  The limitations here are really not bad.
There are no attacks that would be enabled by duplicate keys, and there are
no other tools that provide what we need.  Regardless  of the merits of
I-JSON, the software base doesn't exist, and this spec isn't going to make
it exist (but if it does come to be, then implementations can use it!).
The current text basically says, "use an off-the-shelf parser that works
the way most off-the-shelf parsers work."  It accommodates the limitations
of reality.

Continuing to tilt at this windmill is just going to result in either
killing JOSE deployment or creating a portion of the spec that is
universally ignored.  And moreover, it will demonstrate further how
out-of-touch the IETF is with reality.

--Richard




On Thu, Sep 18, 2014 at 4:06 AM, Tero Kivinen <kivinen@iki.fi> wrote:

> Tim Bray writes:
> > The chance  of the JOSE working group moving the vast world of
> > deployed JSON infrastructure round to 0.00.   Thus putting a MUST
> > reject in here would essentially say you can’t use well-debugged
> > production software, and would be a really bad idea.
>
> And are none of those jose parsers open source? If any of them is open
> source, then someone who wants to use jose, could take one, fix it to
> reject duplicates, and use that still well-debugged production
> software, with small patch, and he just need to add regression test
> case for the new patch, and rerun the normal regression tests to know
> everything else still works.
>
> If all of them are closed source software which you cannot patch, then
> it might be better that people write proper open source parser which
> actually tries to be secure.
>
> > On the other hand, if JOSE specified that producers’ messages MUST
> > conform to I-JSON, and a couple other WGs climbed on that bandwagon,
> > and the word started to get around, I wouldn’t be surprised if a few
> > of the popular JSON implementations added an I-JSON mode.  That
> > would be a good thing and lessen the attack surface of all
> > JSON-based protocols (which these days, is a whole lot of them).
>
> And if we say MUST reject structures with duplicate keys, that would
> perhaps force them even more, especially as those vendors really
> wanting to be conformant would start asking that.
>
> On the other hand, I think most of the vendors would just issue
> request for the fix, but still continue using the relaxed parser,
> regardless what we write in the specification here. At least if we say
> MUST then they hopefully will put the feature request in. If we say
> SHOULD, they will not...
> --
> kivinen@iki.fi
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>