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

Tim Bray <tbray@textuality.com> Thu, 27 June 2013 06:16 UTC

Return-Path: <tbray@textuality.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D8321F9C3D for <jose@ietfa.amsl.com>; Wed, 26 Jun 2013 23:16:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmZBz998WVpw for <jose@ietfa.amsl.com>; Wed, 26 Jun 2013 23:15:57 -0700 (PDT)
Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id DD89E21F9C46 for <jose@ietf.org>; Wed, 26 Jun 2013 23:15:46 -0700 (PDT)
Received: by mail-ve0-f171.google.com with SMTP id b10so296602vea.16 for <jose@ietf.org>; Wed, 26 Jun 2013 23:15:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=mIrNH5XJvcv2hP0vJgLsZorYpTeD8EdAz+3a0/gmKJ8=; b=JFeM+sUYf6YxfY79lW5JoUm09wQuUmr+l4k+yAWSwhybxdtsxXwE3e8m3Blgjrxhze URcYsLMPR/MPxsNB66vmWutGuU3w63TD5QNUX8I3L4ciQkNhk7uZ5W/qhst/fcscwmyP dzN+9V3/SCIYZ56EszQpjrUGcuwFTYERiDbOEXOP6UvnvUyvUmX0Svn0FnPzo8qRCPxO KSbua53S1Dxi5/yPXtN77iXQxQj+mP9bFBwNb9NcZOWkjGwd1TKtoXc47Dy46BcYMZZ1 ZbFRawYnr3vFuoElhOsDN4kZjfhV3uawfPA+rT/O0rna+KklaGJU/CCR87XzLjte/pzw CesA==
MIME-Version: 1.0
X-Received: by 10.58.54.70 with SMTP id h6mr2965254vep.36.1372313745035; Wed, 26 Jun 2013 23:15:45 -0700 (PDT)
Received: by 10.220.219.200 with HTTP; Wed, 26 Jun 2013 23:15:44 -0700 (PDT)
X-Originating-IP: [172.26.52.9]
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151BE45737@WSMSG3153V.srv.dir.telstra.com>
References: <061.bb7bbe0b618ec6b74904f48bdb9bb312@trac.tools.ietf.org> <076.a597050ecb4fb25084cec65f7174dc7e@trac.tools.ietf.org> <033b01ce729b$26ff5c90$74fe15b0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436789B4CC@TK5EX14MBXC283.redmond.corp.microsoft.com> <03b401ce72e5$002c65f0$008531d0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436789D4EA@TK5EX14MBXC283.redmond.corp.microsoft.com> <CAHBU6ivNow2xhDvRj7gG2gmHQ+C-ejEHCQubK=LwUtrXxdW6MA@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1151BE45737@WSMSG3153V.srv.dir.telstra.com>
Date: Wed, 26 Jun 2013 23:15:44 -0700
Message-ID: <CAHBU6itHZ4NvGLyRqfDFaC9gkWD1_6dxhY=uVmwpyL+5Ay+j2w@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: "Manger, James H" <James.H.Manger@team.telstra.com>
Content-Type: multipart/alternative; boundary="089e0122ad064b299004e01cb1d0"
X-Gm-Message-State: ALoCoQmWs9P9LO6uh1ywGY23rg34DMe2U9nX1ICM5CIiPkVS0UE/nmZzGZfZRPdKjQ2aX0up7MmQ
Cc: Mike Jones <Michael.Jones@microsoft.com>, Jim Schaad <ietf@augustcellars.com>, "jose@ietf.org" <jose@ietf.org>, "draft-ietf-jose-json-web-signature@tools.ietf.org" <draft-ietf-jose-json-web-signature@tools.ietf.org>
Subject: Re: [jose] #27: member names MUST be unique needs additional text
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2013 06:16:02 -0000

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 <
James.H.Manger@team.telstra.com> 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
>