Subject: [secdir] Secdir last call review of draft-ietf-calext-jscalendar-26

From: Phillip Hallam-Baker via Datatracker <[email-masked]>
Date: Tue, 10 Mar 2020 07:28:40 -0700

Reviewer: Phillip Hallam-Baker
Review result: Has Issues

The Security Considerations need to be substantially expanded to address:

1) Spam
2) Duplication
3) Time Zones
4) Authentication

The first issue is a major problem with ical attachments, applications assume
that these are authentic and create entries. It is stupid but it is ubiquitous.
There should be note of this as it is a very common channel exploited by
spamers.

Duplication is a related problem. Calendar entries should have a unique
persistent ID and clients should check these so that updates on multiple
devices don't end up resulting in a dozen calendar entries which happens to me
repeatedly.

Time Zones are a related problem it is important to make sure that the time
zone of recurring entries is correctly set. Why is this a security issue?
Because I have been in a situation where a meeting secretary deliberately sent
out a maliciously crafted meeting announcement to make sure the 'wrong people'
didn't attend.

Authentication is my main concern though as my entire home automation system
runs off a a task database that is based on a JSON calendar format which is not
this format _yet_. My plan being to let you folk do the work and then wrap
authentication round it.

So when I am done, the calendar will drive the selection of what happens in the
house. The school calendars will be loaded and these will cause the alarms for
myself and the kids to come on when it is a school day and not otherwise. Same
for heating etc. If one of us is traveling, there will be adjustments etc.

This is obviously a stretch goal but it is clearly something that will be
commonplace at some point. Calendaring systems are going to be about more than
just work appointments. And that means we need authentication. The draft does
not need to say HOW this is done but it does need to say you need to do it.

A related concern is that many companies set up accounts for each meeting room
and you reserve the room for your meeting by 'inviting' it to the meeting. Now
consider doing the same in a serviced office scenario, you want the convenience
but there is also going to be a payments interface because you pay for the
meeting room by the hour.

In the general body of the text, the treatment of recurring events MUST address
time zones and daylight savings. This is the stuff iCal didn't get right at
first and that lead to pain.

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 16 Mar 2020 21:07:32 +1100

Hi Phillip,

Thank you for the review and apologies for the late reply; I have been on leave.

> 4) Authentication

I have expanded the introduction to the security considerations to mention (4) and added sections for (1)-(3); I include the additions and alterations below. Please let me know if you believe this is insufficient:

*7. Security Considerations*

 Calendaring and scheduling information is very privacy-sensitive.
 Its transmission must be done carefully to protect it from possible
 threats, such as eavesdropping, replay, message insertion, deletion,
 modification, and man-in-the-middle attacks.

 The data being stored and transmitted may be used in systems with
 real world consequences. For example, a home automation system may
 turn an alarm on and off. Or a coworking space may charge money to
 the organiser of an event that books one of their meeting rooms.
 Such systems must be careful to authenticate all data they receive to
 prevent them from being subverted.

 This document just defines the data format; such considerations are
 primarily the concern of the API or method of storage and
 transmission of such files.

… 7.1-7.3 as before …

*7.4. Spam*

 Calendar systems may receive JSCalendar files from untrusted sources,
 in particular as attachments to emails. This can be a vector for an
 attacker to inject spam into a user's calendar. This may confuse,
 annoy, and mislead users, or overwhelm their calendar with bogus
 events, preventing them from seeing legitimate ones.

 Heuristic, statistical or machine-learning-based filters can be
 effective in filtering out spam. Authentication mechanisms such as
 DKIM [RFC6376] can help establish the source of messages and
 associate the data with existing relationships (such as an address
 book contact). Misclassifications are always possible however, and
 providing a feedback mechanism for users to quickly correct this is
 advised.

*7.5. Duplication*

 It is important for calendar systems to maintain the UID of an event
 when updating it to avoid unexpected duplication of events. When the
 UID changes, consumers of the data may not remove the previous
 version of the event if it has a different UID. This can lead to a
 confusing situation for the user, with many variations of the event
 and no indication of which one is correct. Care must be taken by
 consumers of the data to remove old events where possible to avoid an
 accidental denial-of-service attack due to the volume of data.

*7.6. Time Zones*

 Events recur in a particular time zone. When this differs from the
 user's current time zone, it may unexpectedly cause an occurrence to
 shift in time for that user due to a daylight savings change in the
 event's time zone. A maliciously crafted event could attempt to
 confuse users with such an event to ensure a meeting is missed.

> first and that lead to pain.

Can you clarify a bit what change you are looking for here, if any? Do you believe the current text in JSCalendar is ambiguous? A recurrence applies to the "start" property of the event, which is a local date-time. All other properties (including "timeZone") are inherited unless overridden for a specific instance. So an event will essentially recur in its time zone; if you need to translate this into UTC you'll of course need time zone information and to account for daylight savings etc.

Cheers,
Neil.