[secdir] Secdir last call review of draft-ietf-calext-jscalendar-26
Phillip Hallam-Baker via Datatracker <noreply@ietf.org> Tue, 10 March 2020 14:28 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D7F3A13D3; Tue, 10 Mar 2020 07:28:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Phillip Hallam-Baker via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: last-call@ietf.org, calsify@ietf.org, draft-ietf-calext-jscalendar.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.120.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158385051998.15836.4770030164750320016@ietfa.amsl.com>
Reply-To: Phillip Hallam-Baker <hallam@gmail.com>
Date: Tue, 10 Mar 2020 07:28:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/ULqVdlaPXN8br0cFpmUKP3qEv5I>
Subject: [secdir] Secdir last call review of draft-ietf-calext-jscalendar-26
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Mar 2020 14:28:41 -0000
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.
- [secdir] Secdir last call review of draft-ietf-ca… Phillip Hallam-Baker via Datatracker
- Re: [secdir] [calsify] Secdir last call review of… Neil Jenkins
- Re: [secdir] [Last-Call] Secdir last call review … Benjamin Kaduk
- Re: [secdir] [calsify] Secdir last call review of… Daniel Migault