Subject: [Jcardcal] Stephen Farrell's Discuss on draft-ietf-jcardcal-jcard-05: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 17 Jul 2013 17:37:48 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-jcardcal-jcard-05: Discuss

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.

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

vCards can be used to represent unexpected stuff that
might have security issues, e.g. see RFC 6869.
Aren't you missing a security consideration here
along the lines of saying that a vCard->jCard
translator that knows the generic syntax but does not
know the sensitivity associated with various vCard
things is very very liable to get something wrong
leading to unexpectd exposures? I'm not sure what
text might work for that, nor am I sure if we can
really ensure that a vCard->jCard convertor (or
vice-versa) will really understand the security
issues with the translations they are doing.

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

- 3.4.3-3.4.5: Would it be worth pointing out a
preferred date/time form for applications that want
to use JOSE data integrity services? Not sure that'd
belong here really but I do wonder where it might
belong.

- 3.4.12 - I expected this to map to RFC 6350 section
5.1 but it doesn't. What if a 6350, 5.1 LANGUAGE
property parameter is present? Where's that go?

- section 6 is missing the boilerplate from rfc6982.
Maybe a bit late, but that's a pity. Is this section
supposed to be removed or kept in the RFC?

- please see the secdir review [1] from which it
seems some changes ought arise.

[1] http://www.ietf.org/mail-archive/web/secdir/current/msg04095.html

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 18 Jul 2013 13:54:34 -0400

Hi Stephen,

> issues with the translations they are doing.

I am weighing in on this because it speaks to the original design goals for 
all the vCard/iCalendar alternate data formats (XML and JSON).

These alternative formats have been designed purely as alternative 
"syntaxes" for the original data formats. They are not intended to have any 
impact on the semantics of the actual data itself. Thus these specs are 
primarily concerned with doing the translation between the data formats, 
and that in itself does not introduce security issues, nor should it - of 
course with the proviso that the "rules" defined int he spec are correctly 
followed.

To address this point perhaps the following replacement for the first 
paragraph in Security Considerations would work (note this tries to fix 
some issues from the SecDir review too):

    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. As a result, all of the security considerations that
    relate to the underlying vCard data, as described in Section 9 of
    [RFC6350], are applicable here.

-- 
Cyrus Daboo

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 18 Jul 2013 19:10:27 +0100

Hi Cyrus,

On 07/18/2013 06:54 PM, Cyrus Daboo wrote:
> I am weighing in on this because it speaks to the original design goals
> for all the vCard/iCalendar alternate data formats (XML and JSON).
> 
> "syntaxes" for the original data formats. They are not intended to have
> any impact on the semantics of the actual data itself. Thus these specs
> are primarily concerned with doing the translation between the data
> formats, and that in itself does not introduce security issues, nor
> should it - of course with the proviso that the "rules" defined int he
> spec are correctly followed.
> 

I think that's an improvement you should make but I still have
a question (to which I don't know of a good answer).

Say some s/w knows that the vCard foobar attribute is sensitive
because the person who wrote the code has read the relevant RFC
and it said to be careful.

Now the vCard -> jCard translation code is generic and so the
person who wrote that code doesn't know that foobar is sensitive.

Isn't there now a new danger that the foobar JSON object/array
might go astray since nobody's written s/w having read the RFC
that says foobar is sensitive?

I'm not sure what'd be right to say about that, but I'm not
convinced that just saying the above (that translating doesn't
"impose or remove and security considerations") is sufficient.

And I can imagine that the jCard version of stuff might get to
unexpected places, so I think this could be a real issue.

Cheers,
S.

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 18 Jul 2013 16:30:48 -0400

Hi Stephen,

> that says foobar is sensitive?

That is not a NEW danger - it could just as well happen with vCard data 
sent as text or XML! In all of those cases it is up to the application 
developer to understand the semantics and requirements of each 
property/parameter they deal with. There are already cases of 
vCard/iCalendar libraries or apps that fail to parse or roundtrip X- 
properties or parameters.

> unexpected places, so I think this could be a real issue.

Again - any format of vCard can go to unexpected places and be mistreated. 
It has always been a requirement of the app developers to understand the 
semantics of the properties and parameters. That point can be re-iterated 
if you want. Here is my proposal for a total replacement of the current 
Security Considerations:

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

-- 
Cyrus Daboo

---

From: Philipp Kewisch <[email-masked]>
Date: Sun, 21 Jul 2013 22:51:56 +0200

On 7/18/13 10:30 PM, Cyrus Daboo wrote:
> Again - any format of vCard can go to unexpected places and be 
> mistreated. It has always been a requirement of the app developers to 
> understand the semantics of the properties and parameters. That point 
> can be re-iterated if you want. Here is my proposal for a total 
> replacement of the current Security Considerations:
>

Sorry, I didn't have this email in mind when answering the SECDIR 
review. Let me see if I can merge the two, let me know what you think.

    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: Cyrus Daboo <[email-masked]>
Date: Mon, 22 Jul 2013 10:03:02 -0400

Hi Philipp,

>     which doesn't arise with conventional vCard data.

So I have a problem with this. I don't see why it is any easier to produce 
a buggy JSON parser than it is to produce a buggy vCard text format parser. 
In fact I would argue it the other way - there are already plenty of 
existing "robust" JSON parsers in use being "tested" on more than just 
jCard data. Whereas for vCard text format, there are some existing 
libraries available but they will have had much less use than a most 
existing JSON parsers.

So I don't think focussing on the robustness of parsers is right. A better 
approach might be to look at where people might start making use of jCard. 
The hope is that jCard results in more vCard data being used by lots of 
different applications, many of which may well be web-based. In such 
contexts, a bug in handling the vCard data that results in a security 
breach could expose much more sensitive data than just contacts. Similarly, 
the use of jCard data within web-apps also exposes that data to flaws in 
those web-apps, so sensitive contact data might be more prone to leaking. 
What is more, amy desktop and mobile OS's now provide a mechanism where 
users have to approve third-party application access to the systems 
built-in contact store. A similar approval mechanism ought to be used for 
web-apps too.

I am really not sure how all that might be wrapped up into some text in the 
draft - at the end of the day just saying "take care to not write buggy 
implementations" really does not contribute much...

-- 
Cyrus Daboo