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

[Stephen Farrell <[e-mail]>]

Hiya,

All below is good, couple of notes below but no pressing need to
follow up further - handling it as you suggest is good.

On 05/10/15 16:52, Cyrus Daboo wrote:
> 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.

Fair enough. It wouldn't be what's usually done, true. It might be
better though if (in general) we moved from naming via DNS to naming
via DNS+some keying material. But that'd probably be better done
when more major changes are being made.

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

I note you didn't answer here, but that's ok. A separate spec
(e.g. "privacy friendly guidelines for developing caldav clients")
could be developed for that (or for caldav in general) at some
other time I guess.

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

That's good but I do think there's a new twist here. The 9th
bullet in that reference does talk about a fake TZ for tracking
but only says a server could do that. With this spec, I think
we're extending the issue to anyone who can create an event
(if a server supports an unknown TZ or if we just use a lesser
used TZ). If I'm right there, then I'd argue to maybe recognise
that here, e.g. by adding something like "This specification
extends the potential privacy issues discussed in [service]
to anyone who can create a calendar event e.g. with a fake or
lesser-used TZ."

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

Nice.

Cheers,
S.


> 
>