Re: [calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-eventpub-extensions-13: (with DISCUSS and COMMENT)

Michael, for my part I like what you've added into the Security
Considerations, in Sections 9.1 and 9.2.

The only thing I would like to see added to what's there is something
in 9.1 explicitly saying that implementations SHOULD NOT dereference
URIs automatically.  Perhaps something like this?:

OLD
   See [RFC3986] for a discussion of the security considerations
   relating to URIs.
NEW
   See [RFC3986] for a discussion of the security considerations
   relating to URIs.  Because of the issues discussed there and below,
   clients SHOULD NOT follow URIs and fetch content automatically,
   and should only do so at the explicit request of the user.
END

Does that make sense?

I might also suggest warning the user about fetching unknown/untrusted
content, but I know how useless such warnings are in practice, and
would prefer that servers block questionable sites and dodgy content
altogether, as you already discuss in 9.2.

Barry

On Fri, Oct 16, 2020 at 2:36 PM Michael Douglass
<mikeadouglass@gmail.com> wrote:
>
> A rather delayed reply to your original message:
>
> Thank you for the suggestions.
>
> I'll submit a version 16 to refresh the draft and, I hope, fix the
> remaining issues
>
> Note that I'd like in particular some feedback on the security/privacy
> section.
>
> On 5/28/19 20:08, Benjamin Kaduk via Datatracker wrote:
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-calext-eventpub-extensions-13: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > I want to talk some about the redefinition of SOURCE.  While I agree
> > that the original definition's applicability is more narrow than it
> > needs to be, that doesn't seem to be enough to convince me that there's
> > enough justification to make it so broad as to provide vcard information
> > about a participant or an event link-back, as opposed to just the
> > canonical source of updates for a given object/component.  I must
> > apologize for having essentially not done a search of the WG discussion
> > archives for this topic, and pointers into the archive could help to
> > convince me that this redefinition is a stable, interoperable, and
> > backwards-compatible choice.
>
> This one I fixed with version 14. My comment and your reply at the time was:
>
> > On this particular issue I've come round to agreeing with the points
> > made here and in other messages. As an alternative i was considering
> > suggesting dropping the VALUE=TEXT. Having a vcard inline can always be
> > handled with a data uri.
> >
> > However, it seems to me that I can come closer to the intent by using
> > the STRUCTURED-DATA property - it is intended to provide supporting data
> > and of course there's no backwards compatibility issues.
> >
> > Does this seem an appropriate way forward?
> Your reply...
> > It seems appropriate to me (with the caveat that I am not a domain expert
> > here).
>
> >
> > The example in Section 5.4:
> >
> >       STRUCTURED-DATA;FMTTYPE=application/ld+json;
> >        SCHEMA="https://schema.org/FlightReservation";
> >        ENCODING=BASE64;VALUE=BINARY:Zm9vYmFy
> >
> > contains an inline value that doesn't seem to decode to a valid
> > FlightReservation JSON object.
> You were correct - fixed the example in version 14
> >
> > Perhaps I'm misreading, but the ABNF in Section 7.6 does not seem to
> > allow for an explicit VALUE=TEXT parameter to be given, and the
> > description does not list TEXT as the default value type.  (I note that
> > the listed example does include VALUE=TEXT, causing this to rise to a
> > Discuss-level internal inconsistency.)
> This I missed - updated ABNF to make VALUE=TEXT required
> >
> > Similarly, the examples in Section 8.1 seem incomplete, since they omit
> > the REQUIRED dtstamp and uid properties.
> In v16 I made dtstamp optional. It is only needed for scheduling. Added
> UID to the examples.
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Section 3
> >
> >     The properties defined here can all reference external meta-data
> >     which may be used by applications to provide enhanced value to users.
> >
> > This sentence seems to raise my hackles for two reasons: (1) it reads
> > like marketing copy and not a technical specification, and (2) it calls
> > to mind analogies to all the privacy-harming technologies that have
> > become pervasive in HTML mail and the web ecosystem: tracking pixels,
> > call-home URLs, etc..  While I agree that loading remote content can be
> > helpful, it is definitely a dual-use technology; I appreciate that the
> > privacy considerations attempt to cover the risks of remote content.
> > Perhaps there is additional room to nod to those risks at this point in
> > the document.
> OK - toned it down a bit and added a caution.
> >
> >     Using STRUCTURED-LOCATION, information about a number of interesting
> >     locations can be communicated, for example, address, region, country,
> >     postal code as well as other informations such as the parking,
> >     restaurants and the venue.  [...]
> >
> > nit: "the parking" is incomplete; perhaps "parking availability"?
> > nit: "restaurants" is also incomplete; perhaps "nearby restaurants"?
> >
> >                             In social calendaring it is often important
> >     to identify the active participants in the event, for example a
> >     school sports team, and the inactive participants, for example the
> >     parents.
> >
> > I share the directorate reviewer's confusion as to what "social
> > calendaring" is.
> Added a section to describe what was meant
> >
> > Section 3.1.1
> >
> >              In addition, there will be sponsorship information for
> >     sponsors of the event and perhaps paid sponsorship properties
> >     essentially advertising local establishments.
> >
> > I'm not sure how much precedent the IETF has for facilitating
> > advertising as a specific goal.
>
> The IETF - like many organizations - welcomes sponsorship and provides
> advertising:
>
> https://ietf.org/about/support/meeting-sponsorship/
>
> Having the opportunity to highlight that information is useful to event
> organizers.
>
> >
> > Section 3.1.2.1
> >
> >     A meeting may have 10 attendees non of which are co-located.  The
> >
> > nit: s/non/none/
> >
> >     current ATTENDEE property does not allow for the addition of such
> >     meta-data.  The PARTICIPANT property allows attendees to specify
> >     their location.
> >
> > nit: PARTICIPANT is a component, not a property.
> Fixed:
> >
> > Section 4
> >
> > Please be more concrete about what actually is changing, e.g., the
> > addition of participantc to eventc/todoc/journalc, as well as the more
> > obvious incremental addition to the properties' ABNF.
> > Making the reader cross-reference to RFC 5545 for each ABNF production is
> > rather unfriendly.
> Added comments to the ABNF
> >
> > Section 5.2
> >
> > Is a video remote conferencing facility assumed to also provide audio
> > functionality?
> >
> > Section 5.3
> >
> > nit: "lowest level of ordering" is perhaps ambiguous (though the
> > subsequent clarification is not); I'd suggest just "as being ordered
> > last".
> >
> >     Example uses:  The ORDER may be applied to the PARTICIPANT-TYPE
> >        property to indicate the relative importance of the participant,
> >        for example as a sponsor or a performer.  For example, ORDER=1
> >        could define the principal performer or soloist.
> >
> > side note: It's not very clear to me that it's going to be possible to
> > assign a complete ordering to all participants once events start getting
> > complicated.  There is the option of just leaving a single low-priority
> > "everybody else" bucket and not worrying too hard, but this feels like
> > something easy that gets a quick win but will not be a full solution.
> > (Which, to be clear, is not necessarily bad.)
> >
> > Section 5.5
> >
> > While I'm sympathetic to not actually putting a full HTML styled
> > description in the example, I'd suggest at least putting in the closing
> > </html> tag.
> Done.
> >
> > Section 7.1
> >
> > nit: is there a reason for active participants to be taking a "role" but
> > inactive ones taking a "part"?
> no -p changed
> >
> > Section 7.3
> >
> > It's not clear to me when one would attach an alternative representation
> > to a STYLED-DESCRIPTION rather than just adding the other representation
> > as another STYLED-DESCRIPTION in its own right.  Presumably this just
> > means I'm not an iCalendar expert, but maybe there is something more
> > subtle going on here.
> >
> > Section 7.4
> >
> > Do we want a reference to RFC 7986 again for the LABEL parameter?
> Added a bunch
> >
> >        When used in a component the value of this property provides
> >        information about the event venue or of related services such as
> >        parking, dining, stations etc..
> >
> > Does this hold universally for all components (e.g., even PARTICIPANT) or
> > only some of them?
> >
> > I don't understand all the discussion about the "Use of the related
> > parameter", which is presumably just my lack of familiarity with
> > iCalendar in general.  But it's surprising that we'd have to worry about
> > timezones and such for events/todos related to a structured *location*.
> This is to align with jscalendar
> >
> > Section 7.5
> >
> >       strucewaval   = ( uri / text )
> >
> > "strucewaval" seems like a typo and does not appear elsewhere in the
> > document.
> It was - corrected
> >
> > Section 8.1
> >
> >     Conformance:  This component can be specified multiple times in a
> >        "VEVENT", "VTODO", "VJOURNAL", or "VFREEBUSY" calendar component.
> >
> >     Description:  This component provides information about a participant
> >        in an event, task or poll.  [...]
> >
> > Why do these two lists have different cardinality?
> Changed wording
> >
> >     Privacy Issues:  When a LOCATION is supplied it provides information
> >        about the location of a participant at a given time or times.
> >        This may represent an unacceptable privacy risk for some
> >        participants.  User agents MUST NOT include this information
> >        without informing the participant.
> >
> > How is this "informing" supposed to work when the participant is not a
> > human (e.g., an organizational SPONSOR or a sports team)?
> >
> > Also, it seems likely that there may be attributes (parameters) other
> > than location that a given individual may not wish to be disclosed, or
> > at least disclosed globally.
> I've added a comment in the privacy section and referred to that. Could
> you take a look at that please?
> > In the last example:
> >
> >                       BEGIN: PARTICIPANT
> >                       SOURCE;FMTTYPE=text/vcard;
> >
> > this last semicolon should be a colon?
> Gone as a result of other changes
> >
> >                        http://dir.example.com/vcard/contacts/contact1.vcf
> >                       PARTICIPANT-TYPE:CONTACT
> >                       DESCRIPTION:A contact:
> >
> > The last colon here is superflous?
> >
> >                       END:PARTICIPANT
> Yes
> >
> > Section 8.2
> >
> > It's not entirely clear to me that we need this much discussion about
> > schedulable PARTICPANTs -- can't we get most of the way with the
> > status quo of ATTENDEE properties being schedulable, and just noting
> > that for such ATTENDEEs, the matching PARTICIPANT may have additional
> > (e.g., location) information?
> We lack a place in the 5545 spec for the SEQUENCE and DTSTAMP for the
> attendee. I wanted to point out this particular use.
> >
> > Section 9.1
> >
> > This example seems to illustrate a weakness of STRUCTURED-LOCATION,
> > namely that it relies upon the human readaing the LABEL parameter to
> > understand what type of relationship the location has to the event.  It
> > seems that calendaring software would be able to present a better
> > interface if there was some structured information available about the
> > type of location, as well as the freeform string of the label.
> That's the point of the LOCTYPE parameter
> >
> > Section 9.2
> >
> > The time gap between DTSTAMP and CREATED is rather large; is that
> > intended?
> No - all the dates are getting old - refreshed them
> >
> > It might also be helpful to give some indication of the meeting room
> > where the event is nominally occurring, so as to make the "At home"
> > location more clearly a remote location.
> >
> > Section 10
> >
> > Potential additional security considerations: the target of the
> > CALENDAR-ADDRESS URLs may have access control on them, and not all
> > recipients of the property may be authorized to access the referenced
> > calendar.  Such access control is properly a matter for the owner of the
> > calendar in question, but it may still be appropriate to mention it
> > here.
> >
> >     Security considerations relating to the "ATTACH" property, as
> >     described in [RFC5545], are applicable to the "STRUCTURED-DATA"
> >     property.
> >
> > I had a quick look in RFC 5545, and neither the labelled Security
> > Considerations section nor any mention of "ATTACH" (with quotes) seemed
> > to cover such security considerations.  What am I missing?
> You are correct. I used a variant of the wording for managed attachments.
> >     When processing HTML content applications need to be aware of the
> >     many security and privacy issues as described in the IANA
> >     considerations section of [W3C.REC-html51-20171003]
> >
> > nits: this needs at least a comma after "content", and possibly another
> > comma before "as described".
> >
> > Section 11
> >
> > There may be some privacy considerations relating to the ORDER
> > parameter, as it provides an indication of some entity (the
> > organizer's?) perception of the relative importance of other
> > participants.
> >
> >     The addition of location information to the new participant component
> >     provides information about the location of participants at a given
> >     time.
> >
> > We probably should go a little further and note that this may facilitate
> > tracking of individuals or malicious actions targeted against them at
> > the known location/time pair.
> I've added more text and aligned this to some extent with jscalendar.
> >
> > _______________________________________________
> > calsify mailing list
> > calsify@ietf.org
> > https://www.ietf.org/mailman/listinfo/calsify
>