Subject: [ietf-calsify] AD review of iMIP I-D

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 12 May 2010 11:23:35 -0600

Because Alexey is my co-AD, I'll act as the sponsoring AD for
draft-ietf-calsify-rfc2447bis. Here are some comments based on my review...

1. The Table of Contents does not match the actual contents (section
names and numbers are different in some places).

2. IMHO we don't need the second two paragraphs of the Abstract.

3. Update iTIP reference to RFC 5546.

4. In Section 2, this issue is confusing:

   The [RFC-5322] "Reply-To" header field typically contains the email
   address of the originator of the scheduling message. <<However, this
   cannot be guaranteed as Mail User Agents (MUA) are not required to
   enforce iMIP semantics.>>

I don't see "scheduling message" defined in RFC 5545 or RFC 5546 (is it
the email message containing the iCAL data or the iCAL data itself?).
However, I think this could be phrased a bit better:

   Ideally the [RFC-5322] "Reply-To" header field of the iMIP message
   will contain the email address of the originator of the scheduling
   message.  However, this cannot be guaranteed because the sender of
   the iMIP message might not be the originator of the scheduling
   message and the sender's Mail User Agent (MUA) might not enforce
   iMIP semantics by translating the originator's address into the
   "Reply-To" email header.

But perhaps that's not what we are trying to say... :)

5. It would be nice to spell out the base64-encoded data from the
DESCRIPTION field of the example in Section 2.5.

6. In Section 3, the term "CU" is not spelled out -- I assume it means
"Calendar User".

7. In Section 3:

   1. The iCalendar object MUST be signed by the "Organizer" sending an
   update/initial request; the "Attendee" sending a reply; or another
   ("uninvited") CU, who was forwarded a REQUEST, sending a reply.  <<Or
   the person sending on their behalf? Clearly if somebody else is
   sending the invitation, she can't sign using the key belonging to the
   organizer>>

Although there is no automated method for discovering whether someone is
an authorized delegate for an Organizer (or an Attendee), a signed iCAL
object from another entity in the same trust domain might provide some
level of assurance regarding authorization (e.g., if the object is
signed by someone else at isode.com then I might have more trust in it
than if it were signed by someone at mail.ru).

[This problem is related to a number of other delegation use cases we've
stumbled upon lately -- Richard Barnes and I plan to write an I-D that
describes this problem for a number of different technologies.]

In any case, the MUST here seems strange, because we are talking about
processing of a signed iMIP message, not generation of a signed iMIP
message. What is the force of the MUST here? Is it REQUIRED for the
processing MUA/CUA to discard the object if it is not signed, or not
signed by the Organizer, an Attendee, or an uninvited calendar user? The
latter entity provides a loophole here anyway, so I'm not sure how
valuable the restriction really is...

Then we have:

   3. Correlate the signer to either an "ATTENDEE" property or to the
   "ORGANIZER" property in the iCalendar object, based on the method and
   the calendar component specified in the iCalendar object, as defined
   in Section 1.4 of [iTIP].  If the signer cannot be correlated to an
   "ATTENDEE"/"ORGANIZER" property (or is not authorized to act on her
   behalf), ignore the message.

Realistically, ignoring the message might be too strict, given that it
will simply discourage people from signing iCAL objects (don't we all
accept unsigned email messages and calendaring invites?). Perhaps we
need some language here similar to what we use for server certificate
checking, such as:

   3. Correlate the signer to either an "ATTENDEE" property or to the
   "ORGANIZER" property in the iCalendar object, based on the method and
   the calendar component specified in the iCalendar object, as defined
   in Section 1.4 of [iTIP].  If the signer cannot be correlated to an
   "ATTENDEE"/"ORGANIZER" property, then actively warn the user
   controlling the calendar user agent that the iCalendar object is
   untrusted and encourage the user to terminate the connection, but
   give advanced users the option to (a) view the signature and the
   entire certificate chain (if any), (b) accept the certificate either
   temporarily (i.e., for this iCalendar object only) or permanently
   (i.e., for all future iCalendar objects), and then (c) continue with
   processing of the iCalendar object.

My reasoning is that a user might have knowledge outside the context of
automated processing that a particular entity has delegated authority to
send (and sign) iCalendar objects on behalf of an Originator or Attendee.

These considerations might lead us to change this paragraph, too:

   It is possible to receive iMIP messages sent by someone working on
   behalf of another "Calendar User". This is determined by examining
   the "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE"
   property.  [iCAL] and [iTIP] provide no mechanism to verify that a
   "Calendar User" has authorized someone else to work on their behalf.
   To address this security issue, implementations MUST provide
   mechanisms for the "Calendar Users" to make that decision before
   applying changes from someone working on behalf of a "Calendar User".
   One way to achieve this is to reject iMIP messages sent by users
   other than the "ORGANIZER" or the "ATTENDEE"s.

8. Also in Section 3:

   If an unsigned iMIP message is received from the same
   sender later on, the receiving CUA SHOULD warn the receiving user
   about a possible man-in-the-middle attack and SHOULD ignore the
   message, unless explicitly overridden by the user. <<Should it also
   try to notify the other end?>>

I don't see a good reason to try to notify the other end -- if there
really is a MITM then presumably Mallory can masquerade as either side.

9. Please spell out URI on first use (Section 2.3) and/or in Section 5.1.

10. In Section 5.1 we have:

   The [iCAL] specification makes frequent use of the URI for data types
   in properties such as "DESCRIPTION", "ATTACH", "CONTACT" and others.
   Two forms of URIs are Message ID (MID) and Content ID (CID). These
   are defined in [RFC-2392]. Although [RFC-2392] allows referencing
   messages or MIME body parts in other MIME entities or stores, it is
   strongly recommended that iMIP implementations include all referenced
   messages and body parts in a single MIME entity. Simply put, if an
   iCalendar object contains CID or MID references to other messages or
   body parts, implementations should ensure that these messages and/or
   body parts are transmitted with the iCalendar object. If they are
   not, there is no guarantee that the receiving CUA will have the
   access or the authorization to view those objects.

s/recommended/RECOMMENDED/ ?

s/should/SHOULD/ ?

That's all I found, but I'm not a MIME expert!

Peter

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

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

_______________________________________________
ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify