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

[Lisa Dusseault]

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@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."

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
>