Subject: [Tzdist] Stephen Farrell's No Objection on draft-ietf-tzdist-caldav-timezone-ref-04: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 30 Sep 2015 06:59:35 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-tzdist-caldav-timezone-ref-04: No Objection

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-tzdist-caldav-timezone-ref/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- 3.1.2: The tzdist protocol says clients SHOULD use TLS. A
question then is ought servers here (be able to) include trust
point information for tzdist for the service in question when
they tell a client to use a particular tzdist service?

- Given the three points below, maybe it is worth specifying
some 'background' kind of traffic to be sent between client and
tzdist services? What do you think? 

- section 4, point 5: that seems onerous - is a client supposed
to retrieve all known timezones from all servers?  What if/when
those change?

- section 8: missing privacy issue: if I create an event using a
weird TZ and can see who accesses the tzdist service, then I can
find out who is subscribed to some calendars maybe. Worth
noting? I don't see what can be done about it, except maybe to
ask clients to occasionally make a random query to the tzdist
service just to confuse matters, but that'd also have downsides
if not done well.

- section 8: missing security issue: if a lot of clients are
fetching this information from a tzdist server, then that
becomes an interesting thing to attack as the consequences could
be significant. Maybe worth noting just to encourage folks to
(document their code so as to get others to) think about this
when deploying.