Subject: [Json] Kathleen Moriarty's No Objection on draft-ietf-json-i-json-05: (with COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Mon, 19 Jan 2015 12:24:07 -0800

Kathleen Moriarty has entered the following ballot position for
draft-ietf-json-i-json-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-json-i-json/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with the SecDir reviewer in his assessment of this draft after
reading it.  I'm putting this in as comments/suggestions to be considered
as the security considerations really should be in the JSON document.  If
any considerations are missing, that is where I'd expect to see them. 
The JSON format is not simple, so  agree with the SecDir reviewer that
one would have expected additional handling considerations for security
purposes to be in that document.  They don't need to be listed in this
one.

Having said that, it might be good idea to add text to the security
considerations section, to state that I-JSON restricts and limits some
of
the dangerous formats of the original JSON, therefore it might be
considered
more secure than the original JSON.  Perhaps also mention that
security critical usages of the JSON should use I-JSON
(perhaps even provide references to the jose specifications).
https://www.ietf.org/mail-archive/web/secdir/current/msg05380.html

---

From: Tim Bray <[email-masked]>
Date: Thu, 22 Jan 2015 18:02:09 -0800

<editor-hat>

I thought that claiming that I-JSON offered qualitatively better security
was a little immodest.  If there’s general agreement with Kathleen and
SecDir, I’d be happy to introduce such language. There are two options:
1. Note that “ I-JSON restricts and limits some of
​​
the danger
​​
ous formats of the original JSON, therefore it might be considered
​​
more secure
​​”
2. Assert that security-critical usages of JSON should (or SHOULD?) use
I-JSON

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 23 Jan 2015 07:34:56 -0500

Hi Tim,

Sent from my iPhone

> On Jan 22, 2015, at 9:02 PM, Tim Bray <[email-masked]> wrote:
> 
> <editor-hat>
> 
> I thought that claiming that I-JSON offered qualitatively better security was a little immodest.  If there’s general agreement with Kathleen and SecDir, I’d be happy to introduce such language. There are two options:
> 1. Note that “ I-JSON restricts and limits some of​​ the danger​​ous formats of the original JSON, therefore it might be considered​​ more secure​​”
> 2. Assert that security-critical usages of JSON should (or SHOULD?) use I-JSON

For coding related issues, security is a bit better when there are limits/restrictions for parsers.  I think Stephen pointed out a few things he thought were going to happen to further restrict, that didn't.  However, your proposed language looks good to me and leaves a little leeway.

Thanks,
Kathleen
> 
> 
>> On Mon, Jan 19, 2015 at 12:24 PM, Kathleen Moriarty <[email-masked]> wrote:
> - Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)

---

From: Tim Bray <[email-masked]>
Date: Sun, 25 Jan 2015 10:17:45 -0800

On Fri, Jan 23, 2015 at 4:34 AM, Kathleen Moriarty <
[email-masked]> wrote:

> For coding related issues, security is a bit better when there are
> limits/restrictions for parsers.  I think Stephen pointed out a few things
> he thought were going to happen to further restrict, that didn't.  However,
> your proposed language looks good to me and leaves a little leeway.
>
>
​Um, which of the two, or both?  Seriously, an IETF-consensus assertion
that security-sensitive people SHOULD use I-JSON feels like a big deal to
me.  However, I think that’s what I’m hearing, so unless there are screams
I’ll go put some combo of #1 and #2 above in the next revision.​

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 25 Jan 2015 14:41:28 -0500

Hi Tim,

Sent from my iPhone

> On Jan 25, 2015, at 1:17 PM, Tim Bray <[email-masked]> wrote:
> 
> On Fri, Jan 23, 2015 at 4:34 AM, Kathleen Moriarty <[email-masked]> wrote:
>>> <editor-hat>
>>> 
> ​Um, which of the two, or both?  Seriously, an IETF-consensus assertion that security-sensitive people SHOULD use I-JSON feels like a big deal to me.  However, I think that’s what I’m hearing, so unless there are screams I’ll go put some combo of #1 and #2 above in the next revision.​

I meant to say #1 as the language wasn't strong, but said enough to be helpful.

Thanks,
Kathleen

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 25 Jan 2015 12:03:00 -0800

I would agree with Kathleen on this.  Its better but not everything is there.

Jim

From: json [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Sunday, January 25, 2015 11:41 AM
To: Tim Bray
Cc: [email-masked]; [email-masked]; Matt Miller; The IESG; [email-masked]
Subject: Re: [Json] Kathleen Moriarty's No Objection on draft-ietf-json-i-json-05: (with COMMENT)

Hi Tim,

Sent from my iPhone

<editor-hat>

​​ 

the danger

​​

​​ 

more secure

​​”

 

Thanks,

Kathleen 

 

Thanks,

Kathleen

 

-- 

 

--

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 25 Jan 2015 22:07:58 +0100

* Tim Bray wrote:
>Um, which of the two, or both?  Seriously, an IETF-consensus assertion
>I’ll go put some combo of #1 and #2 above in the next revision.?

That would pretty much give I-JSON BCP status for all future protocols.
I think such a change requires another Last Call.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 25 Jan 2015 22:19:17 +0100

> I think such a change requires another Last Call.

I don't think that would be right (or that we have consensus for that).

(See the off-IESG thread on the JSON mailing list on Ted Lemon's comment.)

Grüße, Carsten

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 25 Jan 2015 16:46:24 -0500

Sent from my iPhone

> On Jan 25, 2015, at 4:19 PM, Carsten Bormann <[email-masked]> wrote:
> 

This is what we are talking about, a light statement that saying what's different and it might be more secure:

1. Note that “ I-JSON restricts and limits some of the dangerous formats of the original JSON, therefore it might be considered more secure.

I don't think this is enough to be considered a BCP with the wired might, however it is well known that restrictions on formats for parsing helps to reduce/prevent security issues.  
> (See the off-IESG thread on the JSON mailing list on Ted Lemon's comment.)

Do you have the link?

Thanks,
Kathleen

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 25 Jan 2015 22:56:25 +0100

> 1. Note that “ I-JSON restricts and limits some of the dangerous formats of the original JSON, therefore it might be considered more secure.

I'm much more comfortable with that text than with Bjoern's hypothetical
elevation to "BCP" (which is what I was reacting to).

> I don't think this is enough to be considered a BCP with the wired might, however it is well known that restrictions on formats for parsing helps to reduce/prevent security issues.  

One problem is that when you add arbitrary restrictions to what parts of
the data model you can express, this leads to having to add code to work
around those restrictions, which work-arounds may have their own
undesirable security properties.

>> (See the off-IESG thread on the JSON mailing list on Ted Lemon's comment.)

http://www.ietf.org/mail-archive/web/json/current/msg03573.html

Grüße, Carsten