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

[Ken Murchison <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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
>>     [e-mail] <mailto:[e-mail]>
>>
>>
>>     _______________________________________________
>>     calsify mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/calsify
>>
>
>     --
>       Bron Gondwana, CEO, Fastmail Pty Ltd
>     [e-mail] <mailto:[e-mail]>
>
>
>     _______________________________________________
>     calsify mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/calsify
>
>
>
> -- 
> Daniel Migault
> Ericsson
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC