Subject: [APPS-REVIEW] review of draft-ietf-calsify-rfc2447bis (iCalendar Message-Based Interoperability Protocol)

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Feb 2010 07:59:01 -0700

Are there any volunteers to review the MIME binding for calendar objects
provided in rfc2447bis?

https://datatracker.ietf.org/doc/draft-ietf-calsify-rfc2447bis

I know we have some MIME and calendaring experts on this list, and
another set of eyes would be very helpful.

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: SM <[email-masked]>
Date: Tue, 16 Feb 2010 08:30:13 -0800

>https://datatracker.ietf.org/doc/draft-ietf-calsify-rfc2447bis

These are quick comments.  Feel free to use it as part of the review.

The uppercase in the Table of Contents is difficult to read.  FWIW, 
it's the same style as in RFC 2447.  Section number 6 in the Table of 
Contents is incorrect.  The draft has an Author's Address section 
instead of an Editor's Address section.

In Section 2:

   "The [RFC-5322] "Reply-To" header field typically contains the email
    address of the originator of the scheduling message."

That sentence is slightly different from what is in RFC 2447 
(originator or respondent of an event).  From Section 3.6.2 of RFC 5322:

   'When the "Reply-To:" field is present, it indicates the address(es)
    to which the author of the message suggests that replies be sent.'

In Section 2.6:

   "Implementations MAY include a "Content-Disposition" header field to
    define a file name for an iCalendar object.  However, the handling of
    a MIME part MUST be based on its [RFC-2045] "Content-Type" and not on
    the extension specified in the "Content-Disposition", as different
    email malware is known to trick User Agents into misinterpreting
    content of messages by specifying a file extension in the Content-
    Disposition header field that doesn't correspond to the value of
    Content-Type header field."

If I understood RFC 2447 correctly, the filename was added because 
"some environments handle MIME attachments based on their file type 
or extension".  The "Content-Disposition" header field was introduced 
for implementations to operate correctly in those 
environments.  After reading Section 2.6 the draft, I presume that 
this functionality is no longer required.  The last sentence of that 
section explains why it is a bad idea.  The file name in the 
"Content-Disposition" can be use for storing the entity as a file but 
it should not be used to determine the presentation method.

Regards,
S. Moonesamy

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 20 Feb 2010 16:14:24 +0000

Hi SM,
Thanks for the comments.

SM wrote:

> Contents is incorrect.

I wouldn't worry about that, RFC Editor can fix that. (The document 
source is nroff, so maintaining TOC is more effort that I would like to 
spend.)

> The draft has an Author's Address section instead of an Editor's 
> Address section.

I think the section name is more or less fixes. Again, I let RFC Editor 
fix that.

> (originator or respondent of an event).

Yes, but the definition of the "originator" has changed:

  The sections below refer to the "originator" and the "recipient" of an
  iMIP message. In the case of a "request" method, the originator is the
  "Organizer" and the recipient is an "Attendee" of the event. In the
  case of a "response" method, the originator is an "Attendee" and the
  recipient is the "Organizer" of the event.

so I think the two paragraphs taken together are correct.

> From Section 3.6.2 of RFC 5322:
>
> "some environments handle MIME attachments based on their file type or 
> extension".

I am not so sure. Maybe the filename is useful for saving calendars or 
for presenting them to users.

> The "Content-Disposition" header field was introduced for 
> implementations to operate correctly in those environments.  After 
> reading Section 2.6 the draft, I presume that this functionality is no 
> longer required.  The last sentence of that section explains why it is 
> a bad idea.  The file name in the "Content-Disposition" can be use for 
> storing the entity as a file but it should not be used to determine 
> the presentation method.

Are you suggesting to discourage use of Content-Disposition altogether?

Regards,
Alexey

---

From: SM <[email-masked]>
Date: Sat, 20 Feb 2010 14:25:55 -0800

Hi Alexey,
>Are you suggesting to discourage use of Content-Disposition altogether?

The "Content-Type" is used to identify the content information.  If 
the value is "text/calendar", the UA processes the scheduling 
information.  Scheduling messages SHOULD be sent with an alternative, 
human-readable form of the information (Section 2.4) as some user 
agents may not support the content type.  The filename doesn't convey 
scheduling information.

The malware example is most likely similar to:

   Content-Type: audio/x-wav; name="agenda.exe"

If the associated application is determined by using the file 
extension and there isn't anyo prompt (confirm whether the file 
should be run), the code is executed automatically.

Without a Content-Disposition header, the UA can use the presentation 
method it deems suitable.  If you have a "inline" disposition type, 
the information is displayed automatically if the UA supports the 
content-type.  If the disposition type is "attachment", user action 
is required.  Discouraging the use of Content-Disposition does not 
solve the problem.  The actual problem is the handling of the MIME part.

I suggest asking implementers whether dropping Section 2.6 makes 
their application non-compliant with the specification.  You can 
discuss about tricking user agents into misinterpreting the content 
of a message by specifying a file extension as a security consideration.

I'll comment on Section 4.3 as I missed it:

  'Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
   Content-Transfer-Encoding: 7bit
   Content-Disposition: attachment; filename="event.ics" '

This part is an attachment.  The file will be automatically saved 
using that filename or the user will be given a choice to open or 
save the file.

   'Content-Type: application/msword; name="FieldReport.doc"
    Content-Transfer-Encoding: base64
    Content-Disposition: inline; filename="FieldReport.doc"
    Content-ID: <[email-masked]> '

The disposition of this part is inline.  The virus can be launched 
here.  BTW, switching to "attachment" does not protect the user 
against social engineering.

Regards,
S. Moonesamy