Subject: Re: [secdir] secdir review of draft-ietf-json-rfc4627bis-07

From: Tobias Gondrom <[email-masked]>
Date: Wed, 18 Dec 2013 15:55:48 +0000

Hi all,

I re-reviewed the new doc version and did not see any changes related to
my comments nor did I receive any direct replies from the authors.
(note: this might well be due to some technical errors on the IETF mail
server, which I think is fixed now.)
As I am not sure whether my review email was received by the authors,
here it is again.

Best regards, Tobias

as I am not sure whether these

On 06/12/13 19:29, Tobias Gondrom wrote:
> Hi all,
> as it seems my previous review email was not relayed to the secdir and
> iesg mailing-lists. Here it is again.
> Best regards, Tobias
>
>
> On 25/11/13 23:50, Tobias Gondrom wrote:
>> I have reviewed this document as part of the security directorate's
>> ongoing effort to review all IETF documents being processed by the
>> IESG.  These comments were written primarily for the benefit of the
>> security area directors.  Document editors and WG chairs should treat
>> these comments just like any other last call comments.
>>
>>
>> The document updates RFC4627 and aims for Standards Track.
>> It is about the JSON Data Interchange Format
>>
>> This document appears ready for publication.
>>
>> It is good that we make the effort to incorporate the existing errata
>> into an updated RFC.
>>
>> Some small nits / thoughts (as comments, none of them a discuss):
>> - section 1: you briefly explain strings, objects and arrays. Do you
>> maybe also want to make a brief statement about the range of allowed
>> numbers or point towards section 6? (though this is not absolutely
>> necessary as you discuss the data types in more detail in section 4-7). 
>>
>> - section 12.  Security Considerations:
>> second paragraph: the point about the "eval()" function is a bit
>> shallow, it might be useful to discuss this a bit more and to spell
>> out what would be best practice instead of "use that language's
>> "eval()" function to parse JSON texts." as that "generally
>> constitutes an unacceptable security risk"
>>
>> - section 1 or 2:
>> it might be useful to spell out what exactly the most important
>> changes are in comparison to 4627 and why. Or mention that this would
>> be discussed in detail in Appendix A.
>>
>>
>> Best regards, Tobias 
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 18 Dec 2013 08:35:12 -0800

Greetings. I see that we did miss responding to you. We had a very hard time getting consensus in the WG leading to IETF Last Call, so we wanted to keep the changes after that to a minimum. Of your nits:

>>> - section 1: you briefly explain strings, objects and arrays. Do you maybe also want to make a brief statement about the range of allowed numbers or point towards section 6? (though this is not absolutely necessary as you discuss the data types in more detail in section 4-7).  

Our charter was to make as few changes to RFC 4627 as possible, so we left the original prose as-is unless it was actively wrong or caused interoperability issues.

>>> second paragraph: the point about the "eval()" function is a bit shallow, it might be useful to discuss this a bit more and to spell out what would be best practice instead of "use that language's "eval()" function to parse JSON texts." as that "generally constitutes an unacceptable security risk"

The WG didn't come up with any "best practice" other than "don't do that". RFC 4627 includes a (very wrong) example of how to fix the problem, and we didn't want to repeat the mistake of saying "but you might do X instead".

>>> 
>>> - section 1 or 2: 
>>> it might be useful to spell out what exactly the most important changes are in comparison to 4627 and why. Or mention that this would be discussed in detail in Appendix A. 

In this WG, *every* change became important. :-( 

--Paul Hoffman