Skip to main content

Last Call Review of draft-ietf-calext-jscalendar-26
review-ietf-calext-jscalendar-26-secdir-lc-hallam-baker-2020-03-10-00

Request Review of draft-ietf-calext-jscalendar
Requested revision No specific revision (document currently at 32)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-03-09
Requested 2020-02-24
Authors Neil Jenkins , Robert Stepanek
I-D last updated 2020-03-10
Completed reviews Secdir Last Call review of -26 by Phillip Hallam-Baker (diff)
Genart Last Call review of -25 by Robert Sparks (diff)
Secdir Telechat review of -32 by Phillip Hallam-Baker
Assignment Reviewer Phillip Hallam-Baker
State Completed
Request Last Call review on draft-ietf-calext-jscalendar by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/ULqVdlaPXN8br0cFpmUKP3qEv5I
Reviewed revision 26 (document currently at 32)
Result Has issues
Completed 2020-03-10
review-ietf-calext-jscalendar-26-secdir-lc-hallam-baker-2020-03-10-00
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.