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

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Jul 2013 16:15:56 -0400

SECDIR review of draft-ietf-jcardcal-jcard-05

I 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.

This document describes a JSON format for vCard data, as previously 
defined in RFC 6350.

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.

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.

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.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Jul 2013 16:29:40 -0400

Pete,
> Steve,
>
> Are you OK with us forwarding this to the jcardcal mailing list? I 
> think the entire list would benefit by seeing it.
sure.

Steve

---

From: Pete Resnick <[email-masked]>
Date: Wed, 17 Jul 2013 15:24:30 -0500

Steve,

Are you OK with us forwarding this to the jcardcal mailing list? I think 
the entire list would benefit by seeing it.

You are correct that references to "calendar data" in section 7 are 
bogus. It should refer to "contact" or simply "vCard" data. Clearly all 
of us have been standing too close to the document.

Thanks for your comments. We will address them in the document.

pr

On 7/17/13 3:15 PM, Stephen Kent wrote:
> effort to review all IETF documents being processed by the IESG. These 
> directors. Document editors and WG chairs should treat these comments 
> 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.
>
> calendar data security. Does that mean that no other type of vCard 
> use, when using JSON encoding, creates any new security concerns? This 
> draft-ietf-jcardcal-jcal-07), so this narrowly focused comment seems 
> out of place.
>
> 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.
>
> 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 
> 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.
>

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Philipp Kewisch <[email-masked]>
Date: Sun, 21 Jul 2013 21:02:24 +0200

On 7/17/13 10:15 PM, Stephen Kent wrote:
> maps the original vCard data to a new format.However, it then cites 
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.

> indicated, without the calendar data comment.
Taken care of by the previous change.

> without security concerns, if it is properly constrained.The text in 
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.

---

From: Philipp Kewisch <[email-masked]>
Date: Sun, 21 Jul 2013 23:01:29 +0200

> concern that would not arise in a conventional vCard context.
Sorry, I would like to again modify the security considerations in 
reaction to Stephen Farell's DISCUSS/COMMENT and the discussion around 
it. Please ignore my previous reply to the SECDIR review. Here are the 
some of the discussion links for reference:

http://www.ietf.org/mail-archive/web/jcardcal/current/msg00279.html
http://www.ietf.org/mail-archive/web/jcardcal/current/msg00288.html
http://www.ietf.org/mail-archive/web/jcardcal/current/msg00290.html
http://www.ietf.org/mail-archive/web/jcardcal/current/msg00291.html
(one more message by me from a few minutes ago, no link on the archive yet)

Proposed changes, replacing the whole security considerations section:

OLD:

NEW:
    This specification defines how vCard data can be "translated" between
    two different data formats - the original text format and JSON - with
    a one-to-one mapping to ensure all the semantic data in one format
    (properties, parameters and values) are preserved in the other. It
    does not change the semantic meaning of the underlying data itself,
    or impose or remove any security considerations that apply to the
    underlying data.

    The use of JSON as a format does have its own inherent security risks
    as discussed in Section 7 of [RFC4627].  Even though JSON is
    considered a safe subset of JavaScript, it should be kept in mind
    that a flaw in the parser processing JSON could still impose a threat
    which doesn't arise with conventional vCard data.

    With this in mind, a parser for JSON data should be used for jCard
    that is aware of the security implications.  For example, the use of
    JavaScript's eval() function is only allowed using the regular
    expression in Section 6 of [RFC4627].  A native parser with full
    awareness of the JSON format should be preferred.

    In addition, it is expected that this new format will result in vCard
    data being more widely disseminated (e.g., with use in web
    applications rather than just dedicated "contact managers").

    In all cases, application developers have to conform to the semantics
    of the vCard data as defined by [RFC6350] and associated extensions,
    and all of the security considerations described in Section 9 of
    [RFC6350], or any associated extensions, are applicable.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 22 Jul 2013 11:10:58 -0400

Phillip,

Thanks for the edits.  They address my concerns.

Steve
--------
On 7/21/13 3:02 PM, Philipp Kewisch wrote:
>> 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.
>>
>> 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:
>> 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.
>>
>> 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 
> 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:

---

From: Stephen Kent <[email-masked]>
Date: Mon, 22 Jul 2013 16:42:20 -0400

Pjillip,

I like the tone of the new text, but it does need some edits to be
more readable:
>    does not change the semantics (meaning) of the underlying data itself,
>    that a flaw in the parser processing JSON could still introduce a 
> vulnerability
>    With this in mind, any parser used with jCard data should be 
> security-aware.  For example, the use of
>    JavaScript's eval() function is allowed only after applying the regular
>    awareness of the JSON format is preferred.
>
>    data being more widely disseminated (e.g., used in web
>    In all cases, application developers MUST conform to the semantics