Discussion list for revising the IETF's iCal specifications.

headers Eliot Lear | 3 Jun 2008 14:15

Dear all,

This is a reminder that draft-ietf-calsify-2446bis-06.txt is in working 
group last call (WGLC).  Please submit any comments you have now.  Last 
call ends on June 15.

Eliot

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.

	Title		: iCalendar Message-Based Interoperability Protocol (iMIP)
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-calsify-rfc2447bis-05.txt
	Pages		: 22
	Date		: 2008-6-9

This document, iCalendar Message-Based Interoperability Protocol
   (iMIP), specifies a binding from the iCalendar Transport-independent
   Interoperability Protocol (iTIP) to Internet email-based transports.
Calendaring entries defined by the iCalendar Object Model (iCAL) are
   composed using constructs from RFC 2822, RFC 2045, RFC 2046,
   RFC 2047 and RFC 2049.

   This document is a product of Calendaring and Scheduling Standards
   Simplification (calsify) working group. More information about the
   IETF CALSIFY working group activities can be found on the IETF web
   site at <http://www.ietf.org/html.charters/calsify-charter.html>.

   The issue tracker for the Calsify WG is located at:
    <http://www.ofcourseimright.com/cgi-bin/roundup/calsify>

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2447bis-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

3.1 

"   1. The iCalendar object MUST be signed by the "Organizer" sending an
   update/initial request or the "Attendee" 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>>"

This might impact ITIP and possibly iCal, but we may need a mechanism for an
Organizer to sign a security token when creating/authorizing a delegate, and
require that token to be present in anything sent on the Organizer's behalf.
This would be signed by the Organizer with the Organizer's private key, so
that it would be verifiable by decrypting it with the Organizer's public
key. I'm not a security expert, but it could be as simple as encrypting the
Organizer's RFC2822 address as the token and then upon decryption verifying
that it matched that of the Organizer.

After 3.5

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

I would suggest that the answer to this question is "No", because if the
attacker has successfully interposed itself between the "other end" and this
CUA, any notification attempt would notify the attacker, allowing it to
withdraw and remove traces.

[CC'd the working group list]

Hi Lisa,

Overall, I think these comments fall into two categories; editorial and
substantial. I've labeled the issues below, and will start a new thread
on each substantial issue on the list.

AFAIK, none of the issues you mention have been brought up before. In
other words, good catches. ;)

Cheers,
Aki

to, 2008-05-29 kello 13:49 -0700, ext Lisa Dusseault kirjoitti:
> Section references:  Can we break section 3 down for publication?  It  
> would be so much easier to remember and refer to specific sections of  
> this document if we had section "4.4." be the UID parameter section  
> instead of 3.8.4.7.    My eyes just cross at the fourth level of  
> section nesting.  I am probably abnormally insistent about avoiding  
> that fourth hierarchy level, and you may all think I'm crazy to  
> suggest the work and change.  Nevertheless, I'll go ahead and suggest,  
> without any further pressure, a breakdown and ordering that I,  
> speaking as an individual and not as an AD (is that enough  
> disclaimers), would prefer:
> 	Section 3:   iCalendar Syntax
> 		Section 3.1: Content lines
> 		Section 3.2: Value Data Types
> 
> 	Section 4: ICalendar ojects and Components

ma, 2008-06-16 kello 10:03 +0300, ext Aki Niemi kirjoitti:
> > Section 3.2.1:
> > The ALTREP parameter can be used in a lot of places.  I bet it's not  
> > supported everywhere, and some usages of ALTREP could even be  
> > dangerous.  Some health warnings should be added here at least.

I think we have a couple of options here. Either limit exactly on what
properties the parameter can occur out of the TEXT value type
properties. Or, keep it as it is currently defined. 

In any case, some text should be added to the security considerations.
Specifically, what attack vector did you have in mind?

Cheers,
Aki

ma, 2008-06-16 kello 10:03 +0300, ext Aki Niemi kirjoitti:
> > Section 3.6.2: VTODO.  Is it now more common for VTODOs to appear in  
> > the same iCalendar document as VEVENTS?  A few years ago that was not  
> > the case.  Can we now state that user agents SHOULD be able to handle  
> > VTODOs as well as VEVENTS?

Isn't this the implicit assumption already? Namely that if an
implementation is conforming to the specification, it must supports all
of the defined components therein?

Cheers,
Aki

ma, 2008-06-16 kello 10:03 +0300, ext Aki Niemi kirjoitti:
> > Section 3.2.6, DIR parameter:  This should be limited to LDAP URLs  
> > only, if not by requirement then at least by noting that other types  
> > of URLs are likely to be harmful to interoperability.

For maximum interoperability, a mandatory-to-implement choice should be
defined. However, is LDAP even widely enough supported in iCalendar
implementations to justify this? I suspect vCardDAV URLs could in the
future start appearing here as well.

Cheers,
Aki

ma, 2008-06-16 kello 10:03 +0300, ext Aki Niemi kirjoitti:
> > Section 3.2.15: RELTYPE.  What does it mean that a calendar component  
> > referenced is the SIBLING of this one?  How is a user agent supposed  
> > to use this information?  Is this parameter ever used except on  
> > RELATED-TO?  Is it actually in use even there?  Health warnings at  
> > least.

Good question. Is there a use case that requires a relationship beyond
parent-child (which currently is the only *defined* relationship in the
document anyway)?

Cheers,
Aki

There are two issues here.  One is the attack vector, the other is  
interoperability combinatorial problems.

The attack vector we can do very little about without really breaking  
new ground in limiting where URLs can appear and what they can  
contain.  Even then, if some Rails Web application has URLs of the  
structure "http://calapp.example.org/lisa/e1234/delete" to mean  
"Delete the event ID 'e1234' on the 'lisa' calendar" -- and if the  
user has a cookie with a session giving them permissions to do this  
action -- there's not much a client application can reasonably do to  
detect that this might be a bad URL to go fetch.  (And a lot of the  
worst examples are cases of poor Web app design.)

The interoperability issue from combinatorial explosions of where you  
can find the ALTREP parameter and what can be in it, is not an attack  
-- it can happen innocently and even when an application is trying to  
do a creative extension to iCalendar.

One axis is the kind of URL you can see in ALTREP:  what would you do  
with

       DESCRIPTION;ALTREP="imap://michael <at> example.org/INBOX":The  
Fall'98 Wild
         Wizards Conference - - Las Vegas\, NV\, USA

The other axis is seeing ALTREP in places where even if the URL scheme  
is handled elsewhere in the client, it's unclear what it means in  
context:

On Jun 16, 2008, at 3:14 AM, Aki Niemi wrote:

> ma, 2008-06-16 kello 10:03 +0300, ext Aki Niemi kirjoitti:
>>> Section 3.6.2: VTODO.  Is it now more common for VTODOs to appear in
>>> the same iCalendar document as VEVENTS?  A few years ago that was  
>>> not
>>> the case.  Can we now state that user agents SHOULD be able to  
>>> handle
>>> VTODOs as well as VEVENTS?
>
> Isn't this the implicit assumption already? Namely that if an
> implementation is conforming to the specification, it must supports  
> all
> of the defined components therein?

I should add that currently VTODO and VJOURNAL are treated exactly the  
same way as far as requirements are concerned, even though real-world  
use of VTODO is much greater than for VJOURNAL and I'm not even sure  
we can explain how people use VJOURNAL.  So it seems odd that they're  
both assumed to be required but one is really used and the other is  
not.  That kind of thing may lead casual implementors to just ignore  
the implicit requirement, and lump VTODO in with VJOURNAL as something  
they don't really want to figure out how to support.

Again, I can't think of any new requirement that would be a definite  
good thing, but we could easily write an implementation note that  
mentions that VTODOs are increasingly seen in exported ICS files and  
even in iTIP messages and that VEVENTS are ubiquitous.

Mon	Tue	Wed	Thu	Fri	Sat	Sun

						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30

2	June 2013
9	May 2013
2	April 2013
1	March 2013
6	February 2013
5	January 2013
1	December 2012
6	November 2012
1	September 2012
5	August 2012
1	July 2012
3	June 2012
1	April 2012
1	March 2012
2	December 2011
5	November 2011
1	October 2011
2	September 2011
6	August 2011
1	June 2011
2	May 2011
12	April 2011
6	March 2011
1	January 2011
8	December 2010
2	November 2010
9	September 2010
4	August 2010
8	July 2010
3	June 2010
9	May 2010
2	April 2010
5	March 2010
7	February 2010
8	January 2010
5	December 2009
6	November 2009
15	October 2009
12	September 2009
3	August 2009
3	July 2009
9	June 2009
6	May 2009
8	April 2009
1	March 2009
3	February 2009
34	January 2009
9	December 2008
32	November 2008
37	October 2008
16	September 2008
17	August 2008
31	July 2008
23	June 2008
8	May 2008
3	April 2008
21	March 2008
11	February 2008
24	January 2008
14	December 2007
20	November 2007
22	October 2007
50	September 2007
18	August 2007
31	July 2007
38	June 2007
28	May 2007
18	April 2007
83	March 2007
97	February 2007
48	January 2007
20	December 2006
75	November 2006
103	October 2006
96	September 2006
96	August 2006
34	July 2006
26	June 2006
53	May 2006
14	April 2006
9	March 2006
16	February 2006
6	January 2006
3	December 2005
32	November 2005
51	October 2005
32	September 2005
63	August 2005
51	July 2005
14	June 2005
16	May 2005
141	April 2005
16	March 2005
110	February 2005
14	January 2005
15	December 2004
9	November 2004
77	October 2004
101	September 2004
11	August 2004

Re: WGLC: draft-ietf-calsify-2446bis-06.txt && IETF Dublin

I-D ACTION:draft-ietf-calsify-rfc2447bis-05.txt

RE: I-D ACTION:draft-ietf-calsify-rfc2447bis-05.txt

Re: AD review on 2445bis

AD review issue #1: Use of ALTREP (was: Re: Re: AD review on 2445bis)

AD review issue #4: Supporting both VTODO and VEVENT in the same iCalendar stream (was: Re: Re: AD review on 2445bis)

AD review issue #2: DIR parameter (was: Re: Re: AD review on 2445bis)

AD review issue #3: Meaning of RELTYPE parameter value of SIBLING (was: Re: Re: AD review on 2445bis)

Re: AD review issue #1: Use of ALTREP (was: Re: Re: AD review on 2445bis)

Re: AD review issue #4: Supporting both VTODO and VEVENT in the same iCalendar stream (was: Re: Re: AD review on 2445bis)