Re: [Tzdist] [saag] Fwd: WGLC for draft-ietf-tzdist-service-05

[Lester Caine <[e-mail]>]

On 30/01/15 21:20, Daniel Kahn Gillmor wrote:
> On Fri 2015-01-30 12:57:29 -0500, Lester Caine wrote:
>> On 30/01/15 02:13, Daniel Kahn Gillmor wrote:
>>> Clients requesting multiple unusual TZs together are more easily
>>> identifiable to servers, than clients who request only one.  Should
>>> clients request all their interested TZs at once, or spread out their
>>> polling updates over time?  HTTP pipelining is clearly more efficient;
>>> but what are the privacy implications if you have a system service that
>>> does this?
>>
>> I've cherry picked here since the one thing that seems to have been
>> missed is that the main target for tzdist is to provide a mirror of the
>> TZ data. This is a complete set of tz information, and if my own
>> distribution method is followed many of the  'security and tracking'
>> risks being listed can never arise?
> 
> The specification i read seemed to encourage clients to pick up specific
> zones of interest, not the full set of data.  And the draft certainly
> makes allowances for fetching specific sections (by time, by space) of
> the TZ info.  So i'm not sure if what you call "my own distribution
> method" is intended to be the normal use case.  If it is, maybe that
> needs to be highlighted specifically in the draft?
> 
> Is there some set of client profiles (or use cases, if you prefer) that
> are clearly distinct, with different implications?  Can we identify
> them?

If you have not been following the development of tzdist then you will
have missed some of the debate on just how limited the charter of the
workgroup is. ;) The basic premiss should be to get updates to TZ data
out in a timely manor. Some of the other applications are then built on
that. Servicing devices that are not powerful enough to handle a
suitable security software should not be blocked simply because it may
be a security risk. But it should be used within a suitable environment?

>> The clients computer has a local copy of TZ, and any local processing is
>> done against that copy. On a regular basis they ask tzdist if there has
>> been an update to the version of TZ they are using. If yes then all of
>> the are pulled down. A monitoring tap has no idea where the client is?
>> The only know that someone has updated from v to v+1 of the TZ data?
> 
> Yep, this is a useful approach for keeping inside a broader anonymity
> set (but hm, timing issues might still be a concern).
> 
> However, systems using this approach are really solving the general
> problem of "how to i get the latest version/updates of $X" where $X is
> anything digital: software updates already fulfil this role on modern
> operating systems.  A deployed system on the Internet today that doesn't
> have a software update mechanism is probably bound for trouble -- if it
> *does* have a software update mechanism, why not suggest using that for
> the TZ info?  Debian systems just pull in a new version of the tzdata
> package during system updates, for example.  I haven't checked, but i
> would assume that Microsoft Update and Apple's Software Update would
> treat TZ data the same way that they treat other system updates.  Is
> that not the case?

This is EXACTLY the problem that tzdist is chartered to solve, and the
current draft does at least provide a basis to achieve that. Again since
you have not been following you will have missed a lot of detail on just
why the current methods result in missed meetings and other conflicts.
The starting point which HAS now been developed in the current draft is
to provide a versioning system where by historic material can be
published against a publisher/version and later users can download the
matching data set and ask for a current change set from that data.

> Given that the all-tzdata-as-a-software-update mechanism is already
> available, I sort of assumed that this draft was intended for systems
> that don't already have such a mechanism.

The current system is unusable so tzdist provides a means of providing a
mechanism that works. Material being published currently becomes
unusable when the TZ data set used to create  it is simply scrapped for
a new one.

>> Client using subsets of the data such as embedded devices will be asking
>> for a specific timezone, but that traffic will be within a local
>> network. We know already where they are so we don't need any cleaver
>> processing to hide the fact that we are in that physical location? I've
>> just posted about local servers providing a specific subset of data -
>> within the building it's serving - o you already have an even better
>> idea of location than timezone :)
> 
> Are embedded devices guaranteed to be as stationary as you're making
> them out to be?  Some embedded devices are embedded in cars or mobile
> telephones.  Their motion within and between timezones seems like
> something that would have serious privacy implications, if their queries
> are linkable over time.

There are numerous problems with mobile devices not the least working
out just what time one should be using, but once your calendering system
starts moving through several timezones, it make sense to move from a
single zone system to one using a full dataset? You don't know where you
will be next week. Original draft of tzdist required a complete resync
every time you changed server after a change of location ... currently
the only question when a mobile device regains an internet connection is
'has pub/ver been updated'. CURRENTLY mobile devices have an abysmal
mess of versions of TZ data, which tzdist is the ideal solution to clear
up! VTIMEZONE currently needs identifiable data simply because of the
mess in distributed TZ, so fix one and the 'privacy risk' of the other
is unnecessary :)

>> As with just about any system, accessing the data can be abused exposing
>> other information. We do need to identify what are 'secure' ways of
>> accessing the data and what ars insecure, but not exposing anything that
>> could not be deduced by other means anyway.
> 
> To kickstart a privacy considerations section, it might help to work
> from a concrete example (though clearly that won't be an exhaustive
> review).  How about:
> 
> Consider an internet-connected bedside alarm clock (i think this counts
> an embedded device) that i take with me when i travel.  It updates
> itself (using NTP?) to keep it on-time, and it uses this proposed
> mechanism to make sure it's got the TZ up-to-date.  
I have 80 networked devices in the house here.
I would expect to have a local tzdist service on the local network just
as I have a local NTP service. If the job was being done properly then
the timezone information would simply be part of time service, but that
is a different debate. For now the clocks have to be told what timezone
and where to find any DST information. If I move my clock to a new
location it would be nice if the local time/tzdist service provided a
'local' time so the clock updates? We will then be on a local hotel or
office network? So do we need to 'hide' the location?

> What should this device do as a client of this service?  What are the
> privacy implications of these choices?  How do the privacy
> considerations change for the client with respect to a passive or active
> network observer, as compared to the Provider itself?
If I ask the client for his location via a GPS location in order to sort
out his current timezone do I need to worry about 'privacy'? I currently
have to do this simply because offset supplied via the browser is
useless and if I can't get a timezone that way I have to ask the client
to provide one! I have to keep their information private, but that is
the general transmission security problem? Is asking for the TZ data for
a location any different to asking for the opening times of activities
at that location? But I view being able to ask for the TZ data matching
an historic data set where the publisher of that data does not match my
own cached TZ data as not a privacy risk. Anybody intercepting it has no
idea why I'm asking for it. It WOULD be a lot less of a security risk if
we simply has ONE publisher of TZ data which contained the full historic
set of data, but that is outside the charter of the workgroup!

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk