Subject: Re: Where to put VTIMEZONE and VALARM?

From: Alan Davies <[email-masked]>
Date: Tue, 01 May 2001 11:02:02 -0400

You're assuming that an average CU is capable of recognising
a bogus VTIMEZONE, which might be expecting a bit too much.

Remember it's not always easy to tell spam/malicious email
from real email- just look at how email viruses manage to
spread. I wouldn't even expect an average CU to be able to look
at the source of a VTIMEZONE and decide if it's valid or not. If
all CUAs accepted buggy timezones that were presented to them, those
VTIMEZONEs could spread quickly, in a similar manner to viruses-
imagine if my EST5EDT timezone was messed up, but only in the
'standard' portion; I wouldn't realise until October.

It would also be kind of annoying though to be in the position
where another vendor's bugs can mess up my TZ database- "Every
time I get an iCalendar object from John Doe's buggy Development
Beta CUA my Timezone seems to mess up and I have to
restart/reboot/redownload/reinstall/whatever"- it wouldn't feel
like my own CUA was very robust.

--Alan

At 22:01 2001-04-30 -0400, [email-masked] wrote:

>Damon replied on 04/29/2001 07:42:07 PM:
> > But what happens if a malicious app sends out VTIMEZONEs with the
> > same TZIDs as a proper client app? It could mess up your timezone
> > database.
>
>Sounds like you are thinking of some spam or C&S bomb attack.  Ill group 
>all bogus C&S into the "spam" cateogry for this reply.
>
>Well, if I trash the spam then my CUA wont have to store the faked out 
>data and no harm is done.  If it is not C&S spam and I actually want to do 
>some C&S w/the sender then the odds are pretty good that they wont be 
>using some malicious app that wants to hose my local TZ cache.
>
>So I don't yet see that this is a big problem w/Erics suggestion but 
>perhaps Bob or Paul can slap me up side the head and set me right (on this 
>guys!)
>
>Bruce
>===========================================================================
>Bruce Kahn                                INet: [email-masked]
>Iris Associates                          Phone: 978.392.5335
>Westford, MA, USA 01886                    FAX: and nothing but the FAX...
>Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Tue, 1 May 2001 13:17:13 -0400

Alan wrote on 05/01/2001 11:02:02 AM:
> spread. 

Sure, anyone can build a CUA that is not well designed and CUs are more 
than welcome to use it and pay the price ("Ya get what you pay for" and 
"What goes around, comes around" come to mind for both CU and vendor in 
this case).  However, Id hope that a CUA that offers autoprocessing would 
have some kind of smarts in it (ie: "I only want requests from my boss to 
be autoprocessed", "Only process signed iMIP requests from domains X, Y or Z", etc) so that this is not an issue. 

After all, if I dont accept the spam then why would my CUA need or want to 
store the bogus defintions?  The bogus definitions are only useful in the 
context of the iTIP/iMIP message that my CUA is processing to start with 
and if I toss it, I can safely toss the cruft too.

>         I wouldn't even expect an average CU to be able to look
> at the source of a VTIMEZONE and decide if it's valid or not. 

Whoa Hoss.  The CU is not very likely at all to even see the TZ 
defintions.  They see the decoded iTIP request and will generally toss it 
(unless of course they love adding spam to their calendar).  If they for 
some reason accept the spam then Id expect the CUA to require some CU 
involvement before "updating" or 'overwriting" its own TZ definitions.

> If

I think that Erics current proposal is NOT that the bogus defintions would 
be propigated but rather that each app would encode the TZ information 
from its own internal table of TZ definitions.  That is, I may get (and 
for some reason) accept your spam that adds a new 
North_America/Los_Angeles to my system but it will have a different 
product and/or version info in it.  As such my CUA would not be resending 
it out in any of my requests, it would use its own internal table w/its 
own product name and version on it.  If the offending spam came in w/the 
same TZID as my own CUAs then my CUA could safely ignore it (ie: "I 
already know what ~Lotus/Notes/1/North_America/Los_Angeles/ is so I dont 
need to use the senders TZ info")

If for some reason my CUA wanted keep the spam TZ info and it was forged 
so that it appeared to be a 'newer' version of the TZ definition then the 
CUA should have some reasonable behaviour like prompt the CU that a 
'newer' TZ definition is (or "may be") available and what do they want to 
do w/it.  If it came in on some spam then I would expect the CUs to do 
nothing!   Afterall you can only protect a CU from themselves for so long 
before its just 10 lines of code and 10,000 lines of safety netting. 
Better that the CUA make it something that takes cogntive action on the 
part of the CU _before_ the suspect (or real) TZ defs are added to the 
system!! 

> where another vendor's bugs can mess up my TZ database- 

Please reread Erics proposal.  His proposal does not say that your CUA 
would absorb and reuse the bogus TZ info.  I believe that his intent is 
still that your CUA would continue to use its own tables for all outbound 
stuff w/possibly the exception of delegations or "party crashing".  Eric 
can confirm or deny this though.    As such, the bogus data wont be 
mucking up your normal workflow process since it is only applied to the 
entry(s) that it came in on.

> where another vendor's bugs can mess up my TZ database- 
> [Snip, snip]                    it wouldn't feel

Given the format of Erics TZID, your vendor and product ID wont match the 
crufty CUAs vendor and product ID so a poor CUAs defintions wont be 
messing up your CUAs (unless your CUA is poorly designed too and reuses 
someone elses TZ info as their own). 

Bruce