Re: [Json] Security Considerations

Stefan Drees <stefan@drees.name> Sat, 08 June 2013 07:46 UTC

Return-Path: <stefan@drees.name>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98C321F99CD for <json@ietfa.amsl.com>; Sat, 8 Jun 2013 00:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.202
X-Spam-Level:
X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 9Ih1dZrGE7B8 for <json@ietfa.amsl.com>; Sat, 8 Jun 2013 00:46:45 -0700 (PDT)
Received: from mout.web.de (mout.web.de [212.227.15.4]) by ietfa.amsl.com (Postfix) with ESMTP id A718D21F99A6 for <json@ietf.org>; Sat, 8 Jun 2013 00:46:44 -0700 (PDT)
Received: from newyork.local.box ([93.129.147.120]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0MP2Sl-1UhfcU3JSR-006KoY; Sat, 08 Jun 2013 09:46:19 +0200
Message-ID: <51B2E149.5010503@drees.name>
Date: Sat, 08 Jun 2013 09:46:17 +0200
From: Stefan Drees <stefan@drees.name>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Peter brooks <peter.h.m.brooks@gmail.com>
References: <51B0E02E.4070209@crockford.com> <1BD0044B-D7A6-4C7F-899E-5D3E72C62956@vpnc.org> <51B116FE.9050406@crockford.com> <CAFtB7BSvQi+1p7LYm1WT6Vd1EmLcTN1p8=dpYMOnzu0P4v8K2Q@mail.gmail.com> <20130608034016.GJ2528@mercury.ccil.org> <BFC314C1-F4F1-428D-B2AB-A967BEC9F4F3@gmail.com>
In-Reply-To: <BFC314C1-F4F1-428D-B2AB-A967BEC9F4F3@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:svK5Tag71kTDwM4McNeGSMIge/z4Snflp0SDj3031F7Ve7A70lY w0O1oEC4Ziuow5qqXIM74THxgk57XSp0CoRWIhkK3Ce86FX5zHDrL2lb8ozBZGDq78pbkxo rJZerZGtLscYUVJI7k+d3yQbFFa1kta3zA/boz5H1eilBFEgrr8wPo1WAj3fFYDEcm4JObb fqrhDM6p9tlo0gmvUzIkQ==
Cc: John Cowan <cowan@mercury.ccil.org>, Paul Hoffman <paul.hoffman@vpnc.org>, Douglas Crockford <douglas@crockford.com>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Security Considerations
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stefan@drees.name
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Jun 2013 07:46:50 -0000

On 08.06.13 09:00, Peter Brooks wrote: ...
> On 8 Jun 2013, at 05:40, John Cowan ... wrote:
>> Peter Brooks scripsit:
>>
>>> If JSON messages are exchanged in cleartext, that, itself, is
>>> an indication that they are public and unimportant, so the risk, even
>>> if they are intercepted and modified, is low.
>>
>> Open text is not necessarily unimportant text.  Consider these email
>> messages, which are sent en clair.
>>
> I agree. This, though, is bad practice. Any responsible organisation
> ought to encrypt its sensitive information.

No, please do not label "any" cleartext exchange of broadly classified 
"sensitive information" as a generally "bad practice". For "secrets" ok, 
but "sensitive"? No, not in general.

Every communication has its setup phase, many communication channels 
over time change in the degree of what the impact of the transported 
data on the participants or others might be, even time may change the 
amount of "sensitivity" (like the words and deeds of a young person 
might interfere later with the same person later and in unintended ways).

Shaping the future JSON Format for Data Interchange is also possibly 
much more "sensitive" (as it impacts all conforming future JSON 
messages), than attacking the integrity, confidentiality, or flow of 
some JSON text instances based on that spec ;-)

All the best,
Stefan.