Subject: Re: [calsify] Working Group Last Call: draft-ietf-calext-valarm-extensions-01

From: Ken Murchison <[email-masked]>
Date: Mon, 13 Jul 2020 14:31:56 -0400

Hi Daniel,

Thanks for the review and sorry for my slow reply.  Responses inline.  I 
just posted -02 with a few changes and can make more if required.

On 6/15/20 3:48 PM, Daniel Migault wrote:
> Hi,
>
> I apologize for the very late comments. I hope this helps and I do not 
> believe this goes beyond nits in any cases.
>
> Yours,
> Daniel
>
>
>                     VALARM Extensions for iCalendar
>                  draft-ietf-calext-valarm-extensions-01
>
> 1.  Introduction
>
>    The iCalendar [RFC5545] specification defines a set of components
>    used to describe calendar data.  One of those is the "VALARM"
>    component which appears as a sub-component of "VEVENT" and "VTODO"
>    components.  The "VALARM" component is used to specify a reminder for
>    an event or task.  Different alarm actions are possible, as are
>    different ways to specify how the alarm is triggered.
>
>    As iCalendar has become more widely used and as client-server
>    protocols such as CalDAV [RFC4791] have become more popular, several
>
> <mglt>
> I guess there is an wording issue. I suppose that " have become more 
> popular" should be removed.
>
> </mglt>

I'm not sure exactly what the issue is with the current wording, but I 
changed "popular" to "prevalent".

>
> [ .... ]
>
> 3.  Extensible syntax for VALARM
>
>    Section 3.6.6 of [RFC5545] defines the syntax for "VALARM" components
>    and properties within them.  However, as written, it is hard to
>    extend this by adding, e.g., a new property common to all types of
>    alarm.  Since many of the extensions defined in this document need to
>    extend the base syntax, an alternative form for the base syntax is
>    defined here, with the goal of simplifying specification of the
>    extensions.
>
>    A "VALARM" calendar component is re-defined by the following
>    notation:
>
>    alarmcext  = "BEGIN" ":" "VALARM" CRLF
>                 alarmprop
>                 "END" ":" "VALARM" CRLF
>
>    alarmprop  = *(
>
>                 ; the following are REQUIRED,
>                 ; but MUST NOT occur more than once
>
>                 action / trigger /
>
>
>
>
> Daboo & Murchison         Expires July 20, 2020       [Page 3]
> 
> Internet-Draft              VALARM Extensions January 2020
>
>
>                 ; one set of action properties MUST be
>                 ; present and MUST match the action specified
>                 ; in the ACTION property
>
>                 actionprops /
>
>                 ; the following is OPTIONAL,
>                 ; and MAY occur more than once
>
>                 x-prop / iana-prop
>
>                 )
>
>    actionprops = audiopropext / disppropext / emailpropext
>
> <mglt>
> I believe this should go after *ext have been defined, though I am not 
> very familiar with ABNF.
> </mglt>

It is standard with ABNF (at least as far as I have seen) to structure 
the definitions this way.

>
>    audiopropext  = *(
>
>                    ; 'duration' and 'repeat' are both OPTIONAL,
>                    ; and MUST NOT occur more than once each,
>                    ; but if one occurs, so MUST the other
>
>                    duration / repeat /
>
>                    ; the following is OPTIONAL,
>                    ; but MUST NOT occur more than once
>
>                    attach
>
>                    )
>
>    disppropext = *(
>
>                  ; the following are REQUIRED,
>                  ; but MUST NOT occur more than once
>
>                  description /
>
>                  ; 'duration' and 'repeat' are both OPTIONAL,
>                  ; and MUST NOT occur more than once each,
>                  ; but if one occurs, so MUST the other
>
>                  duration / repeat
>
>                  )
>
>    emailpropext = *(
>
>                   ; the following are all REQUIRED,
>
>
>
> Daboo & Murchison         Expires July 20, 2020       [Page 4]
> 
> Internet-Draft              VALARM Extensions January 2020
>
>
>                   ; but MUST NOT occur more than once
>
>                   description / summary /
>
>                   ; the following is REQUIRED,
>                   ; and MAY occur more than once
>
>                   attendee /
>
>                   ; 'duration' and 'repeat' are both OPTIONAL,
>                   ; and MUST NOT occur more than once each,
>                   ; but if one occurs, so MUST the other
>
>                   duration / repeat
>
> <mglt>
> I have the impression that attach is missing as OPTIONAL that MAY 
> appear more than once.
>
> </mglt>
>

Yes, good catch.

>
> 4.  Alarm Unique Identifier
>
>    This extension adds a "UID" property to "VALARM" components to allow
>    a unique identifier to specified.  The value of this property can
>
> <mglt>
> to be specified
> </mglt>

Fixed.

>
>    then be used to refer uniquely to the "VALARM" component.
>
> [ ... ]
>
>
> 6.  Alarm Acknowledgement
>
>    There is currently no way for a "VALARM" component to indicate
>    whether it has been triggered and acknowledged.  With the advent of a
>    standard client/server protocol for calendaring and scheduling data
>    ([RFC4791]) it is quite possible for an event with an alarm to exist
>    on multiple clients in addition to the server.  If each of those is
>    responsible for performing the action when an alarm triggers, then
>    multiple "alerts" are generated by different devices.  In such a
>    situation, a calendar user would like to be able to "dismiss" the
>    alarm on one device and have it automatically dismissed on the others
>    too.
>
> <mglt>
> It is probably due to my lake of expertise, but I have the impression 
> the acknowledgment properties only works under some conditions. 
> Typically, I imagine that devices not being connected, are hosting the 
> VALARMS components locally, in which case, these devices will not 
> consider the acknowledgment properties.
> Similarly, when devices are connected to a centralized calendar, I 
> suppose - but might completely wrong - that the alarms are 
> simultaneously sent to the various devices. The ability to switch off 
> all alarms relies on the ability of these devices to be able to synch 
> the calendar objects. I am wondering if most systems have a push 
> mechanism to "switch off" the alarms on the other devices.
> </mglt>

The mechanism for "switching off" alarms on devices, is that each device 
should sync the iCalendar resource with the server just prior to firing 
the alarm.  If the VALARM contains an ACKNOWLEDGED property on/after the 
trigger time, then the device should not fire the alarm.

For disconnected devices, there is no solution that I'm aware of.

>
> [ ... ]
>
> 6.1.  Acknowledged Property
>
>    Property Name:  ACKNOWLEDGED
>
>    Purpose:  This property specifies the UTC date and time at which the
>       corresponding alarm was last sent or acknowledged.
>
>    Value Type:  DATE-TIME
>
>    Property Parameters:  IANA and non-standard property parameters can
>       be specified on this property.
>
>    Conformance:  This property can be specified within "VALARM" calendar
>       components.
>
>    Description:  This property is used to specify when an alarm was last
>       sent or acknowledged.  This allows clients to determine when a
>       pending alarm has been acknowledged by a calendar user so that any
>       alerts can be dismissed across multiple devices.  It also allows
>       clients to track repeating alarms or alarms on recurring events or
>       to-dos to ensure that the right number of missed alarms can be
>       tracked.
>
>       Clients SHOULD set this property to the current date-time value in
>       UTC when a calendar user acknowledges a pending alarm. Certain
>       kinds of alarm may not provide feedback as to when the calendar
>       user sees them, for example email based alerts.  For those kinds
>       of alarms, the client SHOULD set this property when the alarm is
>       triggered and the action successfully carried out.
>
>       When an alarm is triggered on a client, clients can check to see
>       if an "ACKNOWLEDGED" property is present.  If it is, and the value
>       of that property is greater than or equal to the computed trigger
>       time for the alarm, then the client SHOULD NOT trigger the alarm.
>
> <mglt>
> Just for clarification, I assume that the computed trigger time 
> defined by the TRIGGER property corresponds in the case of a repeated 
> alarm to the first occurence of the alarm. and the control only apply 
> to the repeated alarms. More specifically, unless I am missing 
> something, it seems hard to me to have an ACKNOWLEDGED time before the 
> alarm is triggered for the first time.
>
> I suspect some checks should be done on the acknowledged time and make 
> sure the time is not in the future.
> </mglt>
>

There is a computed trigger time that corresponds to each occurrence.  
Does that clarify?

> [ ... ]
>
> 9.  Security Considerations
>
>    VALARMs, if not monitored properly, can be used to "spam" users and/
>    or leak personal information.  For instance, an unwanted audio or
>    display alert could be considered spam.  Or an email alert could be
>    used to leak a user's location to a third party or to send
>    unsolicited email to multiple users.  Therefore, CalDAV clients and
>    servers that accept iCalendar data from a third party (e.g. via iTIP
>    [RFC5546], a subscription feed, or a shared calendar) SHOULD remove
>    all VALARMs from the data prior to storing in their calendar system.
>
> <mglt>
> As an attacker, I am wondering if I can format also an acknowledgment 
> or snoozing property to avoid or limit the alarm.
> Suppose I am able to provision an acknowledgment property with a time 
> greater than the computed triggered time. Unless the system controls 
> the acknowledged time from the client, it seems to me feasible that 
> the acknowledged time  is set in the future. Even with such control, 
> it could also disable the repeat properties.

In order to do this via CalDAV, the attacker would have to have 
credentials to update the iCalendar resource.  If they have the user's 
credentials, they can do a lot more damage than just silencing alarms.

>
> I am also wondering how loosely synchronized devices may interfere 
> between each other. I do not see major issues as the time is always 
> related to the time of the event. Loose time synchronization does not 
> seem - but I might be wrong - the calendar objects, but will impact 
> the time acknowledgment / snoozing properties are received, if there 
> are any checks.

I'm not sure I follow.

>
>
> </mglt>
>
> 10.  Privacy Considerations
>
>    Proximity VALARMs, if not used carefully, can leak a user's past,
>    present, or future location.  For instance, storing an iCalendar
>    resource containing proxmity VALARMs to a shared calendar on CalDAV
>    server can expose to anyone that has access to that calendar the
>    user's intent to leave from or arrive at a particular location at
>    some future time.  Furthermore, if a CalDAV client updates the shared
>    iCalendar resource with an ACKNOWLEDGED property when the alarm is
> <mglt>
> I think that is an additional ACKNOWLEDGED property.
>
> While PROXIMITY gives an exact location, the intention. I am unsure 
> about the information ACKNOWLEDGE by itself provides (without 
> proximity). Typically, as far as I understand, it indicates the user 
> has seen the alarm, but does not give the reason that is whether he is 
> willing to ignore the alarm or going to the event itself.  Am I 
> missing something ?
> </mglt>

A proximity alarm would trigger when you arrive/leave a certain 
location.  If the user acknowledges the alarm, then they would leak WHEN 
they where at that location.  I'm open to new suggested text.

>    triggered, will leak the exact date and time that the user left from
>    or arrived at the location.  Therefore, CalDAV clients that implement
>    proximity alarms SHOULD give users the option of storing and/or
>    acknowledging the alarms on the local device only and not storing the
>    alarm and/or acknowledgment on a remote server.
>
>
>
> On Wed, Jun 10, 2020 at 8:32 AM Bron Gondwana <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Obviously, that date came and went and I got sidetracked with
>     other things.  I will submit this document and we don't need to
>     put it on the agenda for the interim next week!
>
>     Cheers,
>
>     Bron.
>
>     On Wed, Apr 22, 2020, at 22:29, Bron Gondwana wrote:
>>     As there's been no feedback on the list about this document and
>>     Ken believes it's complete, we agreed in yesterday's interim
>>     meeting to take this one to WGLC.
>>
>>     We'll make it 3 weeks, so you have until *Wednesday 13 May *to
>>     review and respond to this document.
>>
>>     Cheers,
>>
>>     Bron.
>>
>>     --
>>       Bron Gondwana, CEO, Fastmail Pty Ltd
>>     [email-masked] <mailto:[email-masked]>
>>
>>
>>     _______________________________________________
>>     calsify mailing list
>>     [email-masked] <mailto:[email-masked]>
>>     https://www.ietf.org/mailman/listinfo/calsify
>>
>
>     --
>       Bron Gondwana, CEO, Fastmail Pty Ltd
>     [email-masked] <mailto:[email-masked]>
>
>
>     _______________________________________________
>     calsify mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/calsify
>
>
>
> -- 
> Daniel Migault
> Ericsson
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 13 Jul 2020 15:33:51 -0400

Hi Ken,

--On Mon, 13 Jul 2020 14:31:56 -0400 Ken Murchison <[email-masked]> 
wrote:

> should sync the iCalendar resource with the server just prior to firing the
> alarm.  If the VALARM contains an ACKNOWLEDGED property on/after the

Actually that is not the typical case. Certainly devices should pre-check 
the ACKNOWLEDGED property before triggering the alarm, but in most cases 
that will not be set.

The typical case has alarms triggering simulataneously on all the devices 
belonging to a user. Those will popup an alert on all devices. The user then 
acks the alert on one device. That device adds the ACKNOWLEDGED property and 
writes the event back to the server. The server then triggers a push 
notification to the other devices. The other devices sync the changed event. 
The other devices spot the presence of the ACKNOWLEDGED property and 
automatically dismiss the visual alert.

It might be worth noting one operational consideration here: there is a 
"stampeding herd effect" caused by this ack behavior. Specifically, in 
enterprise enrvironments, meetings often occur at the start of an hour. 
Those meetings can often involve multiple attendees, each of whom may setup 
their own alarm. So servers will get hammered with lots of requests when the 
alarms trigger and start to get ack'd by the users. That gets multipled by 
the number of devices each user has, since those will receive a push 
notification and then sync the ack changes from the server.

In our enterprise system, we saw very large spikes in requests on the hour, 
a smaller spike at 45 mins past the hour, and further smaller spikes at 15 
mins and 30 mins past the hour. There were typically large spikes at 9 am/10 
am/11 am, smaller at 12 pm/1 pm (lunch time), then bigger again at 2 pm/3 
pm, and tailing off after that. These were all traced to the alarm ack 
behavior . In our case, the client defaults to setting up alarms 15 mins 
before a meeting (though many people change that to occur at the time of the 
meeting) - hence the noticeable spike at 45 mins past the hour. That, 
combined with meetings that start on the half-hour, give rise to the pattern 
we saw.

I am not sure if this issue should be described in the spec, but it was 
definitely a performance/scaleability issue that had to be accounted for.

> For disconnected devices, there is no solution that I'm aware of.

Correct. The user would have to manually dismiss UI alerts on all 
disconnected devices.

-- 
Cyrus Daboo

---

From: Daniel Migault <[email-masked]>
Date: Fri, 31 Jul 2020 14:40:36 -0400

Hi,

Thanks for the responses. I will write the shepherd to meet the milestone,
so that should be shipped in a few hours.

Yours,
Daniel

> changed "popular" to "prevalent".
<mglt>
not remembering exactly why I put this comment - I wonder if I was not
myself omitting an "and". In any case, you are better qualify to tell the
wording is fine.
<mglt>

> It is standard with ABNF (at least as far as I have seen) to structure the
> definitions this way.
>
>
> <mglt>
My comment was brought from errors raised by the tools.  I do not find this
as  a big issue - especially if you are telling me you are adopting a
standard way to present.
</mglt>

> I have the impression that attach is missing as OPTIONAL that MAY appear
> more than once.
>
> </mglt>
>
>
> Yes, good catch.
>
>
>
>
> It is probably due to my lake of expertise, but I have the impression the
> acknowledgment properties only works under some conditions. Typically, I
> imagine that devices not being connected, are hosting the VALARMS
> components locally, in which case, these devices will not consider the
> acknowledgment properties.
> Similarly, when devices are connected to a centralized calendar, I suppose
> - but might completely wrong - that the alarms are simultaneously sent to
> the various devices. The ability to switch off all alarms relies on the
> ability of these devices to be able to synch the calendar objects. I am
> wondering if most systems have a push mechanism to "switch off" the alarms
> on the other devices.
> </mglt>
>
>
> Just for clarification, I assume that the computed trigger time defined by
> the TRIGGER property corresponds in the case of a repeated alarm to the
> first occurence of the alarm. and the control only apply to the repeated
> alarms. More specifically, unless I am missing something, it seems hard to
> me to have an ACKNOWLEDGED time before the alarm is triggered for the first
> time.
>
yes.
</mglt>

> As an attacker, I am wondering if I can format also an acknowledgment or
> snoozing property to avoid or limit the alarm.
> greater than the computed triggered time. Unless the system controls the
> acknowledged time from the client, it seems to me feasible that the
> acknowledged time  is set in the future. Even with such control, it could
> also disable the repeat properties.
>
>
correct. I think I was thinking locally at the time of the comment, but as
you state, such attacker may access far more interesting information.
</mglt>

>
> I am also wondering how loosely synchronized devices may interfere between
> each other. I do not see major issues as the time is always related to the
> time of the event. Loose time synchronization does not seem - but I might
> be wrong - the calendar objects, but will impact the time acknowledgment /
> snoozing properties are received, if there are any checks.
>
>
> I'm not sure I follow.
>
>
>
>
>
> </mglt>
>
> While PROXIMITY gives an exact location, the intention. I am unsure about
> the information ACKNOWLEDGE by itself provides (without proximity).
> Typically, as far as I understand, it indicates the user has seen the
> alarm, but does not give the reason that is whether he is willing to ignore
> the alarm or going to the event itself.  Am I missing something ?
> </mglt>
>
>
> A proximity alarm would trigger when you arrive/leave a certain location.
> If the user acknowledges the alarm, then they would leak WHEN they where at
> that location.  I'm open to new suggested text.
>
>
> <mglt>
Seems fine. I think I mis-interpreted the proximity alarm.
</mglt>

> On Wed, Jun 10, 2020 at 8:32 AM Bron Gondwana <[email-masked]>
> wrote:
>
>> Obviously, that date came and went and I got sidetracked with other
>> things.  I will submit this document and we don't need to put it on the
>> agenda for the interim next week!
>>
>> Cheers,
>>
>> Bron.
>>
>> As there's been no feedback on the list about this document and Ken
>> believes it's complete, we agreed in yesterday's interim meeting to take
>> this one to WGLC.
>>
>> We'll make it 3 weeks, so you have until *Wednesday 13 May *to review
>> and respond to this document.
>>
>> Cheers,
>>
>> Bron.
>>
>> --
>>   [email-masked]
>>   [email-masked]
> calsify mailing [email-masked]://www.ietf.org/mailman/listinfo/calsify
>
> --
> Kenneth Murchison

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Fri, 31 Jul 2020 14:48:21 -0400

That is an interesting comment. I am not sure if it should be placed in the
main body of the document or in the security consideration section.

Yours,
Daniel

On Mon, Jul 13, 2020 at 3:33 PM Cyrus Daboo <[email-masked]> wrote:

> the

-- 
Daniel Migault
Ericsson