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

[Cyrus Daboo <[e-mail]>]

Hi Stephen,

--On September 30, 2015 at 6:59:35 AM -0700 Stephen Farrell 
<[e-mail]> wrote:

> - 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?

As in the CalDAV server includes some certificate information about the 
tzdist servers it connects to, so the clients can verify they see the same 
details when they connect? I think that is probably going a step too far 
given all the usual requirements to verify the tzdist service certs.

> - 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?

The client definitely needs to retrive the full time zone data for any time 
zones it is using in calendar data - there is no way around that. Beyond 
that they are really not required to retrive all time zone data. For those 
time zones they do retrive, they do need to keep those up to date by 
following suggestions in the tzdist protocol spec.

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

I will add a new Privacy Considerations section that references the tzdist 
protocol privacy section (which is very comprehensive):

9.  Privacy Considerations

   The privacy recommendations in Section 9 of the Time Zone Data
   Distribution Service [I-D.ietf-tzdist-service] specification SHOULD
   be used to ensure that details of clients' interactions with CalDAV
   servers are not exposed to potential network observers.

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

I can add the following as a new paragraph in the security considerations:

   This specifications adds Time Zone Data Distribution Service
   [I-D.ietf-tzdist-service] servers into the overall calendaring and
   scheduling client/server architecture, as a critical component, and
   thus adds a new vector of attack against such systems.  As such,
   administrators of CalDAV servers SHOULD ensure that any advertised
   time zone distribution servers are protected by a level of security
   commensurate with all the other components in the system.


-- 
Cyrus Daboo