Ballot for draft-ietf-calext-extensions
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
If I am late for the discussion: please put this into substate "revise ID needed". Thank you.
The author has addressed all my DISCUSS points and comments in email. (Thanks!). I've cleared on the assumption the proposed text will make it into a revision.
Dan Romacanu did the OPS DIR review. The RFC5706 does not apply.
Thanks for the updated text to address the SecDir review and Stephen's additional comments (I followed that discussion as well).
I think it'd be a fine thing if the calext WG were to consider privacy issues with caldav in general. As it'd probably be wrong to try get all of that done in this one document, perhaps we could try and see if the WG have sufficient interest and cycles to take that on? My previous discuss text (plus an additional point about images is below. - 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. 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.