Re: [calsify] Secdir last call review of draft-ietf-calext-jscalendar-26

[Daniel Migault <[e-mail]>]

Thanks Phil for the review. This is a useful review with related experience. Thanks Neil for addressing the these comments.

Yours,
Daniel
________________________________
From: Neil Jenkins <[e-mail]>
Sent: Monday, March 16, 2020 6:07 AM
To: Phillip Hallam-Baker <[e-mail]>; [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [calsify] Secdir last call review of draft-ietf-calext-jscalendar-26

Hi Phillip,

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

1) Spam
2) Duplication
3) Time Zones
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.

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.

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.