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

[Pete Resnick <[e-mail]>]

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

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]