Re: [secdir] SECDIR review of draft-ietf-jcardcal-jcard-05

[Stephen Kent <[e-mail]>]

Phillip,

Thanks for the edits.  They address my concerns.

Steve
--------
On 7/21/13 3:02 PM, Philipp Kewisch wrote:
>
> On 7/17/13 10:15 PM, Stephen Kent wrote:
>>
>> This document cites the Security Considerations section of original 
>> vCard RFC (noted above) as the primary content for its Security 
>> Considerations section. It asserts that no new security concerns 
>> arise with respect to _calendar data_, because this specification 
>> merely maps the original vCard data to a new format.However, it then 
>> cites the Security Considerations section of the JSON specification 
>> (RFC 4627) noting that there are additional security risks that arise 
>> from using JSON to represent vCard data! To me these two statements 
>> seem somewhat contradictory, but that can be addressed by refining 
>> the wording here.
>>
>> More worrisome is the fact that this very brief section mentions only 
>> calendar data security. Does that mean that no other type of vCard 
>> use, when using JSON encoding, creates any new security concerns? 
>> This document is much broader in scope than just iCal data (the 
>> subject of draft-ietf-jcardcal-jcal-07), so this narrowly focused 
>> comment seems out of place.
>>
> Yes, this was a copy/paste fail from the jCal draft. I've corrected 
> both instances of "calendar" to "vCard".
>
> OLD:
>    For security considerations specific to calendar data, see Section 9
>    of [RFC6350].  Since this specification is a mapping from vCard, no
>    new security concerns are introduced related to calendar data.
>
> NEW:
>    For security considerations specific to vCard data, see Section 9 of
>    [RFC6350].  Since this specification is a mapping from vCard, no new
>    security concerns are introduced related to vCard data.
>
>> RFC 6350's Security Considerations section notes few concerns that 
>> are Vcard-specific; most of the comments in that section relate to 
>> the need to provide security for vCards when they are transported, 
>> e.g., via email. All of these concerns are equally applicable here, 
>> as indicated, without the calendar data comment.
>>
> Taken care of by the previous change.
>
>> RFC 4627's security considerations section turns out to be an 
>> indirect reference to two paragraphs in the IANA Considerations 
>> section! (This seems silly and it's not clear why that document was 
>> published with such an obvious structural error, but ...). The 
>> security concern cited in 4627 is that JavaScript (JS) is a scripting 
>> language and thus JSON might be used to execute malicious JS. However 
>> JSON is intended to be a "safe" subset of JS, i.e., it should be able 
>> to be evaluated in JS without security concerns, if it is properly 
>> constrained.The text in 4627 provides two regular expressions that 
>> can be invoked to strip any characters that might cause security 
>> problems. I'd feel a lot more comfortable if this text were 
>> explicitly replicated in this I-D, and the I-D _mandated_ this 
>> processing step before passing the Jcard data to JS. (It might even 
>> make sense as a post processing step as part of the vCard to JCard 
>> processing described in Section 3.) The level of indirection 
>> currently used in the Security Considerations section, and the casual 
>> advisory nature of the original text might easily be overlooked by an 
>> implementer.
>>
>> Finally, the notion of JSON as "safe" JS subset assumes that the 
>> parser processing the JSON does not have a security flaw. Such flaws 
>> have been identified, one as recently as February of this year. It 
>> might be good to note that this represents a new type of security 
>> concern that would not arise in a conventional vCard context.
>>
> As most popular JavaScript implementations use JSON.parse() for 
> parsing JSON data, I don't see the need to put this into Section 3. 
> I've changed the text to include the regex and a little more 
> information from what you wrote via email, let me know what you think:
>
> OLD:
>    The use of JSON as a format does have security risks.  Section 7 of
>    [RFC4627] discusses these risks.
>
> NEW:
>    The use of JSON as a format does have security concerns.  Even though
>    JSON is considered a safe subset of JavaScript, this does not ensure
>    that the parser processing JSON does not have a security flaw. When
>    processing jCard data, this concern should be taken into account as
>    it doesn't arise with conventional vCard data.
>
>    As with JSON, when passing jCard data to JavaScript's eval()
>    function, certain precautions must be taken to ensure that no
>    security issues arise.  Specifically, all characters not enclosed in
>    strings MUST exclusively be in the set of characters that form JSON
>    tokens.  This can be quickly determined in JavaScript with two
>    regular expressions and calls to the test and replace methods.
>
>    var my_jCal_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
>           text.replace(/"(\\.|[^"\\])*"/g, ''))) &&
>       eval('(' + text + ')');
>
>    See also Section 7 of [RFC4627] for security considerations of the
>    JSON format.