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

[Daniel Migault <[e-mail]>]

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
On Mon, Jul 13, 2020 at 2:31 PM Ken Murchison <[e-mail]> wrote:

> 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".
>
<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>

>
>
>
> [ .... ]
>
> 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.
>
>
> <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>

>
>
>    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?
>
>
> <mglt>
yes.
</mglt>

>
> [ ... ]
>
> 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.
>
>
> <mglt>
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>
>
> 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.
>
>
> <mglt>
Seems fine. I think I mis-interpreted the proximity alarm.
</mglt>

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

-- 
Daniel Migault
Ericsson