AD review issue #1: Use of ALTREP (was: Re: [Ietf-calsify] Re: AD review on 2445bis)

[Aki Niemi]

ma, 2008-06-16 kello 08:55 -0700, ext Lisa Dusseault kirjoitti:
> 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.)

Right, I do agree there are a lot of things that bad web application
design is susceptible to here. But I don't see how this is especially
bad for iCalendar; it's simple enough to put URLs for images in an
HTML-formatted email, and achieve the same result. In fact, the
probablility of success in exploits this way is bound to be higher as
well (some mail applications actually follow the links).

> 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@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:
> 
>          DUE;ALTREP="http://timezones.example.org/tz/America-Los_Angeles.ics 
> ":19980430T000000Z
> 
> I don't have good answers about what to do about this.  If we lock  
> down what's allowed to a very narrow set of options, this limits  
> extensibility.  That would also be a lot of work.
> 
> Would it be too much work to collect a list, not necessarily complete,  
> of URL schemes that are used in ALTREP and a list of properties that  
> they're seen on ?  Then an implementation note could simply say  
> "Although the URL schemes used in ALTREP are not limited, in deployed  
> implementations as of 2008 one tends to see only HTTP URLs.   
> Similarly, although ALTREP can be used on any property, deployed  
> implementations seem to use it  (dereference and/or display) only when  
> it appears on the Comment, Description and Status properties, and the  
> parameter is often ignored on other properties."

Do you mean summary not status? 

May I suggest an alternative approach? Since the list of "known" uses of
ALTREP can actually be narrowed down to about three, I think we should
add to the definition of each of these properties exactly what it means
to receive one with the ALTREP parameter that contains an HTTP URL.
Other URIs permitted, but their meaning is undefined. In other words,
document current practice as much as we can, but keep further uses open.

And then to ALTREP parameter, add the description you propose, as
generic advice to how the parameter should be handled/used.

Cheers,
Aki


> Lisa
> 
> On Jun 16, 2008, at 2:56 AM, Aki Niemi wrote:
> 
> > 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
> >
>