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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 18 July 2013 18:11 UTC

Message-ID: <51E82F93.5080109@cs.tcd.ie>
Date: Thu, 18 Jul 2013 19:10:27 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: Cyrus Daboo <cyrus@daboo.name>
References: <20130718003748.2045.65683.idtracker@ietfa.amsl.com> <533259592EFE6C6AB8016877@caldav.corp.apple.com>
In-Reply-To: <533259592EFE6C6AB8016877@caldav.corp.apple.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: jcardcal@ietf.org, The IESG <iesg@ietf.org>, jcardcal-chairs@tools.ietf.org, draft-ietf-jcardcal-jcard@tools.ietf.org
Subject: Re: [Jcardcal] Stephen Farrell's Discuss on draft-ietf-jcardcal-jcard-05: (with DISCUSS and COMMENT)
Precedence: list

Hi Cyrus,

On 07/18/2013 06:54 PM, Cyrus Daboo wrote:
> Hi Stephen,
> 
> --On July 17, 2013 at 5:37:48 PM -0700 Stephen Farrell
> <stephen.farrell@cs.tcd.ie> wrote:
> 
>> 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.
> 
> 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.

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.

>

[Jcardcal] Stephen Farrell's Discuss on draft-iet… Stephen Farrell
Re: [Jcardcal] Stephen Farrell's Discuss on draft… Cyrus Daboo
Re: [Jcardcal] Stephen Farrell's Discuss on draft… Stephen Farrell
Re: [Jcardcal] Stephen Farrell's Discuss on draft… Cyrus Daboo
Re: [Jcardcal] Stephen Farrell's Discuss on draft… Philipp Kewisch
Re: [Jcardcal] Stephen Farrell's Discuss on draft… Cyrus Daboo