AD review issue #1: Use of ALTREP (was: Re: [Ietf-calsify] Re: AD
review on 2445bis)
lisa at osafoundation.org
Mon Jun 16 08:55:52 PDT 2008
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
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
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."
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?
More information about the Ietf-calsify