Subject: [calsify] Stephen Farrell's Discuss on draft-ietf-calext-extensions-03: (with DISCUSS)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 29 Jun 2016 03:54:19 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-calext-extensions-03: 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-extensions/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

- I think adding some privacy considerations to this would be good,
either as new text or via references.  Did the WG consider privacy
issues? Some that occur to me are:

   - names, descriptions and identifiers here are all ones that
     might allow (re)identification in unexpected ways

   - the UID property in particular probably ought be random and
     probably ought not be re-used for anything else, some RFC2119
     SHOULD statements about that would seem like they'd be good.

   - doing a refresh against a calendar at the expected frequency
     could be a good way to re-identify someone - if I can read the
     expected frequency and some IP address connects (even all over
     TLS) at about that regularity then I can be reasonably sure
     that the client is someone subscribed to that address, and
     maybe use that to track a person's movement across various
     networks. (That's different from the text in section 7 which
     assumes that the URL is what's tracked, but the connection
     can be just as revealing, for some calendars.)

I'm not trying to insist all that analysis be documented in this
draft but I would hope that the WG have considered the issues and
how best to document those and have a plan to do that. (If I'm told
such a plan exists and what it is, I'll clear.)

This is related to, but a little different from, Kathleen's discuss,
depending on the added privacy considerations text which I've not
managed to find in the secdir review thread.  But this should be as
easily cleared I'd guess.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Jun 2016 12:13:47 +0100

Hi Stephen,

>      SHOULD statements about that would seem like they'd be good.

Can you elaborate on what the concern is with UID, I don't understand?
(As far as I know, it is used for calendar resynchronization when the
same even can be change in different ways on 2 or more devices)

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 Jun 2016 12:33:45 +0100

Hiya,

> same even can be change in different ways on 2 or more devices)

I'm not objecting at all to there being a UID for a calendar, just
saying that it probably ought not be re-used for anything else, e.g.
don't just re-use a UUID that happens to also correspond to the same
user for some other purpose for example. And saying to randomly
generate UIDs/UUIDs is probably also a good idea. It's possible that
that's already implicitly the case, but I didn't see it in this draft.

But the main point of the discuss though is not the set of things
that occurred to me after a quick read, but rather to ask if the WG
had thought about this stuff, and if so, what's the plan?

And another possible issue now occurs to me: I remember that one
social network had an issue where all the avatar image sizes were
nearly unique, so that even though those were all accessed over TLS,
one could identify users and their buddies by watching those be
downloaded. (That depended on how the social network in question
made avatar images available, which'll likely be different here.)
But there may be a reason to recommend normalising image sizes here
as well and to encourage only offering those over https and not
http.

I'm sure folks who know calendaring much better that I do would
likely come up with additional issues, and would certainly know
better which are real concerns, and which aren't.

Cheers,
S.

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 29 Jun 2016 12:20:23 -0400

Hi Stephen,
Please see the new -04 draft which has added a privacy section, and also 
has changes to the security section.

>      might allow (re)identification in unexpected ways

Privacy issues were not specifically considered by the WG (in fact the 
privacy section was only recently added). Please review the current privacy 
section in the -04 draft. In addition, I will add the following paragraph 
(and the one indicated later in this email):

   In general, users have to rely on the privacy policies of any
   conferencing system being accessed via the "CONFERENCE" property, for
   their own privacy protection.  It is entirely possible for such
   systems to uniquely identify and log the activity and participation
   (or not) of calendar users in the conference.  Calendar user agents
   SHOULD track which conferencing systems are used and warn users the
   first time a new one is about to be used.  This is particularly
   important if the client automatically "dials in" to the conference
   when the event start time occurs.

>      SHOULD statements about that would seem like they'd be good.

The definition of "UID" comes from 5545, which already states:

    The "UID" itself MUST be a globally unique identifier.

However, 5545 then goes on to suggest "good" ways to create it which 
include use of domain and IP literals, which are clearly not appropriate 
any more. So, given this draft is updating 5545, do we want to correct that 
now by making a stronger statement that the UID value should be "opaque"? 
My implementations just generate UUIDs - perhaps that should be a new 
recommendation. If we want to do that, then I would add additional text in 
section 5.3 as well as the privacy section. But the question is whether it 
is appropriate for this draft to attempt such a fix - I think that is 
something the working group will need to comment on.

>      can be just as revealing, for some calendars.)

I propose adding the following to the privacy section:

   By giving different calendar users different values for the "REFRESH-
   INTERVAL" property, it is possible for a publisher of calendar data
   to uniquely identify each refresh from each calendar users' clients,
   and thereby track user activity and IP address over time.  To address
   this, clients SHOULD add or subtract some random amount of time from
   the published "REFRESH-INTERVAL" value when doing actual refreshes.

-- 
Cyrus Daboo

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 Jun 2016 17:37:14 +0100

Hiya,

On 29/06/16 17:20, Cyrus Daboo wrote:
> privacy section was only recently added). 

Ah ok. Is that something that needs further work, either here
or perhaps better as a separate document that considers privacy
issues with caldav? If so, do you think there might be folks
who'd be interested in doing that work?

I'm guessing that the answers might be "yes" and "umm, not
sure" in that order:-)

Anyway, I'll clear my discuss on this document and chat with
Alexey tomorrow on the call (or via email is fine too) about
the general issue and whether it's feasible to think about
some folks doing work on that.

> Please review the current
> privacy section in the -04 draft. In addition, I will add the following
> paragraph (and the one indicated later in this email):
> 
> any more. So, given this draft is updating 5545, do we want to correct
> that now by making a stronger statement that the UID value should be
> "opaque"? My implementations just generate UUIDs - perhaps that should
> be a new recommendation. If we want to do that, then I would add
> additional text in section 5.3 as well as the privacy section. But the
> question is whether it is appropriate for this draft to attempt such a
> fix - I think that is something the working group will need to comment on.
> 

All of the above are good additions. (Did you see the additional
point I raised about image size normalisation in a mail with
Alexey? Including that too might be good.)

Cheers,
S.

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 29 Jun 2016 12:42:22 -0400

Hi Stephen,

> as well and to encourage only offering those over https and not

I will add the following to the first paragraph of the privacy section:

    In particular, calendar publishers
   wishing to help protect the privacy of their subscribers MUST use
   HTTP with Transport Layer Security [RFC7230] ("https:" URIs instead
   of "http:" URIs) for access to calendar data or ancillary data such
   as images.

> better which are real concerns, and which aren't.

Will comment on this in a reply to your follow-up email.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 29 Jun 2016 12:48:34 -0400

Hi Stephen,

> some folks doing work on that.

Yes this is ain interesting area to consider. The first question is how is 
calendar data any different from other types of data that may be accessed 
via authenticated or anonymous services (which ought to be covered by 
generic documents covering security and privacy for any data access 
protocol). Obviously there are unique aspects of calendar data that have to 
be considered and thus could be called out separately.

This is something that is becoming more and more important as we see much 
more public event use as well as event/calendar sharing in both enterprise 
and consumer services. There is a bunch of work on CalDAV-based calendar 
sharing that is starting to be discussed at the IETF and will hopefully 
make its way to a working group - so there will be plenty of opportunity to 
discuss this in more detail there.

> Alexey? Including that too might be good.)

Yes, just dealt with that - processing IESG messages serially rather than 
in parallel :-)

-- 
Cyrus Daboo

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Jun 2016 17:57:32 +0100

Hi Cyrus,

On 29/06/2016 17:20, Cyrus Daboo wrote:
> Hi Stephen,
> Please see the new -04 draft which has added a privacy section, and 
> also has changes to the security section.
>
> include use of domain and IP literals, which are clearly not 
> appropriate any more. So, given this draft is updating 5545, do we 
> want to correct that now by making a stronger statement that the UID 
> value should be "opaque"? My implementations just generate UUIDs - 
> perhaps that should be a new recommendation. If we want to do that, 
> then I would add additional text in section 5.3 as well as the privacy 
> section. But the question is whether it is appropriate for this draft 
> to attempt such a fix - I think that is something the working group 
> will need to comment on.

With no hats: as you already updating RFC 5545, you might as well add 
this text. But yes, I would like to hear comments from other 
implementors if they think your text is sensible or not.
(I think it is.)

Best Regards,
Alexey

---

From: Ken Murchison <[email-masked]>
Date: Wed, 29 Jun 2016 19:04:52 -0400

Hi Alexey,

On 06/29/2016 12:57 PM, Alexey Melnikov wrote:
>> then I would add additional text in section 5.3 as well as the 
>> privacy section. But the question is whether it is appropriate for 
>> this draft to attempt such a fix - I think that is something the 
>> working group will need to comment on.
>

I'm comfortable recommending UUIDs.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University