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

From: Cyrus Daboo <[email-masked]>
Date: Sun, 01 Feb 2015 12:03:30 -0800

Hi Paul,

--On January 31, 2015 at 2:34:46 PM -0800 Paul Eggert <[email-masked]> 
wrote:

>> some devices such as central heating controllers
>> would not need a processor capable of the sort of processing power
>> needed to handle that
>
> Even the lowliest central heating controller can easily handle the entire
> tz database, if only to discard unneeded parts as they're received.
> We're talking kilobytes here, not gigabytes or even megabytes.

Well in this day and age the IETF really ought to also require an 
"Environmental Considerations" section in specs too, alongside "Security" 
and "Privacy". If that were a factor here (and I don't see why it would not 
be) then clearly sending all the data (and throwing away all but one) vs 
sending just one tz is an added impact on power usage for all devices 
involved (servers, clients, network hardware). Yes we are talking about 
kilobytes per device but you have to multiply that by the number of devices 
(which with internet of things is only going to increase beyond what we 
have now).

As with everything there are trade offs involved here. For a personal 
device, yes I do want strong privacy for key aspects of data that device 
might use (the obvious one being location information). However, for 
"fixed" devices, like a wall-clock in an office building, in all likelihood 
the exposure of revealing what time zone it is configure to use is likely 
small.

At this point I do think it worthwhile to give clients the option to chose 
what is appropriate for them given the trade offs. So it does make sense to 
provide a "full set of tz data" option in the protocol to allow clients to 
get the entire set of current data without exposing which specific time 
zone(s) they are actually interested in (which would also remove the need 
for them to use etags). How about a "getall" action using a /allzones URI 
to retrieve all the data. The only tricky part might be explaining how the 
data is returned. For iCalendar-based formats that is easy as multiple 
VTIMEZONEs would be included in a single VCALENDAR calendar object. For the 
binary tz data format, I am not sure whether simply concatenating the 
binary data for all tzs is valid - that is something that that format will 
need to be clear about.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Sun, 01 Feb 2015 17:30:35 +0000

On 01/02/15 20:03, Cyrus Daboo wrote:
> "Environmental Considerations" section in specs too, alongside
> "Security" and "Privacy". If that were a factor here (and I don't see
> why it would not be) then clearly sending all the data (and throwing
> away all but one) vs sending just one tz is an added impact on power
> usage for all devices involved (servers, clients, network hardware). Yes
> we are talking about kilobytes per device but you have to multiply that
> by the number of devices (which with internet of things is only going to
> increase beyond what we have now).
> 
> "fixed" devices, like a wall-clock in an office building, in all
> likelihood the exposure of revealing what time zone it is configure to
> use is likely small.

This is actually a good point. One of the 'cost cutting' exercises IS to
eliminate the need for a mains power supply since modern devices need so
little power so while power over the network cable is a more recent
'development', many current central heating controllers have a couple of
AA batteries and a not to 'replace every few years'. So adding paper
displays, they can go to sleep for most of the time and any unnecessary
software cycles are a drain :)

> At this point I do think it worthwhile to give clients the option to
> chose what is appropriate for them given the trade offs. So it does make
> sense to provide a "full set of tz data" option in the protocol to allow
> clients to get the entire set of current data without exposing which
> specific time zone(s) they are actually interested in (which would also
> remove the need for them to use etags). How about a "getall" action
> using a /allzones URI to retrieve all the data. The only tricky part
> might be explaining how the data is returned. For iCalendar-based
> formats that is easy as multiple VTIMEZONEs would be included in a
> single VCALENDAR calendar object. For the binary tz data format, I am
> not sure whether simply concatenating the binary data for all tzs is
> valid - that is something that that format will need to be clear about.

One thing that I have only just twigged is that what we are  talking
about here is just sending the one data package with everything in! If
something is not spelt out it is often missed. I still see the 'power
saving' capabilities of a 'changed since' data package flagging
centrally just which TZis's need to be looked at, and a complete diff
package rather than a full dump again would reduce packet size, but
there is no security risk from that either way?

I still see the major advantage of tzdist in it's ability to flag that
something needs looking at. If I'm not following the affected TZid's
then it's up to me if I even update, but I only really see that being
necessary if there are several competing publishers each using their own
set of data for some 'political or commercial' reason so while we select
a default local one, third party material may well need our accessing
other services :(

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

---

From: Paul Eggert <[email-masked]>
Date: Sun, 01 Feb 2015 13:29:39 -0800

Cyrus Daboo wrote:
> it does make sense to provide a
> "full set of tz data" option in the protocol to allow clients to get the entire
> set of current data without exposing which specific time zone(s) they are
> actually interested in (which would also remove the need for them to use etags).

Yes.  Although clients could omit etags, my guess is that it'd be OK in most 
cases privacy-wise to use them, so long as the etags are global (one per tz 
database version, e.g., "tz2015a") rather than per-server-and-database-version 
(e.g., "tz2015a-04F56E6866304E628CA1C45B").  That way, etags should provide 
little tracking info.  A bonus is that a client could switch servers without 
having to re-get the tz database from the new server.

> For the binary tz data format, I am not sure
> whether simply concatenating the binary data for all tzs is valid

It's not, unfortunately.  Concatenation works for tzdata sources (so long as all 
identifiers are unique), but not for tzdata binaries.  Operating system updates 
solve this by shipping tarballs, perhaps with some other info thrown in.

One thought is to add to the tz distribution, so that it also contains a single 
smallish source file that represents all the tz data.  This file could be 
distributed via tzdist and clients could then run the equivalent of 'zic' to 
convert it to binary form, if that's what they want.  This should be more 
compact than shipping binary files.  The new source file would be in addition to 
the existing source files, which would not need to change (this is for backward 
compatibility to existing build procedures).  This part should be fairly easy to 
arrange.

---

From: Lester Caine <[email-masked]>
Date: Mon, 02 Feb 2015 08:54:33 +0000

On 01/02/15 21:29, Paul Eggert wrote:
> Yes.  Although clients could omit etags, my guess is that it'd be OK in
> most cases privacy-wise to use them, so long as the etags are global
> (one per tz database version, e.g., "tz2015a") rather than
> per-server-and-database-version (e.g.,
> "tz2015a-04F56E6866304E628CA1C45B").  That way, etags should provide
> little tracking info.  A bonus is that a client could switch servers
> without having to re-get the tz database from the new server.

A debate on how an etag is generated on another list implies that is
should include a hash of the data, but I am sure that the spec does not
require that and allows a fully defined etag? The strong/weak element
could come into play where the 'style' of data is an addition, but every
reply with a  'tz2015a' head would contain the same core data (ignoring
backzone problem). I'm not sure if that is necessary if the request
identifies the correct style required, but either way the tag itself is
generic world wide and can be accepted when a different server has to be
accessed for any reason.

In the context of the 'changedsince', asking for 'latest' where one is
currently using 'tz2014j' will return a new packet with 'tz2015a' while
asking for 'changedsince=tz2014j' will return just the differences. If
'latest' returns a complete data dump then the local machine has to work
out if there are any changes which require further work, while the
difference set if sent as a simple list of TZid's allows the client to
ignore any update they are not using id's from. It is up to them if they
download a 'full dump', just the TZid's that have changed, or only the
one's they are using.

For embedded devices asking for a simple 'expand' etag will give them a
'same' message until the version changes. If there is a version change,
but it does not affect the content of this particular packet then one
could say that they don't need to do anything, but given that this is
such a rare occurrence, simply downloading again is fine. If the client
does need to know if the next transition has changed then that is best
handled locally. For this action I don't see that downloading a complete
data set is necessary at all? Since the cache mechanism will time out at
regular intervals, even the etag mechanism will give a reply when
nothing has changed?

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 02 Feb 2015 11:32:15 -0500

Hi Eliot--

thanks for the feedback.

On Sat 2015-01-31 07:08:26 -0500, Eliot Lear wrote:

> I think there are several categories of issues that you've raised, and
> I'd like to break them out.  The first is the easy category: that which
> has been raised before and considered.  There is only one issue in that
> category as to whether or not everything should run atop TLS.  That
> issue need not be reconsidered, EXCEPT in as much as you have clarified
> the context (c2s versus s2s).

Clarifying the c2s vs. s2s scenarios for TLS would definitely be useful.

> There is another category of that which really must change.  Most (if
> not all) of what you mark as security is in this category.  The
> downgrade attack that is possible in the current text also does not
> match my understanding of the consensus of the working group.  That is-
> either a client uses HTTP or it uses HTTPS, but it may not "try" HTTPS
> first, and then back off to HTTP.  "Do.  Do not.  There is no try."

If we can spell this out explicitly in the draft, that would be good.  I
wonder if this is maybe something that would contribute to the idea of
"profiles of operation".  If there is a profile for low-power,
in-network devices, that profile could allow HTTP access, restricting
fetches from the local network's tzdist provider, and accept the
linkability implications (and the resulting lack of privacy for the
device).

This would suggest a second profile for other devices: those that have
higher bandwidth available, more compute power, and should not be
willing to make the linkability/privacy tradeoff in the same way.

Is there a third profile, some sort of device, service, or operating
system that fits in the middle here?  Naming the profiles explicitly and
being clear which features of the spec are intended for which profile
might make the privacy considerations easier to write.

It might also turn out that there are features that fit in no realistic
profile, and can therefore be dropped to simplify the spec.

> The other issues break down into two groups, I think.  Authenticated
> sessions versus unauthenticated sessions.  Because authentication is
> allowed, and because we do not specify a provisioning mechanism, likely
> there will be linkage between services.  But we should also be mindful
> of what mitigations are truly available to us with regard to the other
> functions.

Authenticated sessions clearly provide linkability between repeat
sessions of the same client to the server.  Depending on other choices
made by the network configurations involved (e.g. the use of stable TLS
session IDs, or padding/timeskew choices), those sessions may
*also* leak some linkable information to a passive network attacker (i
haven't yet considered an active network attacker whose goal is to link
sessions).

But unauthenticated sessions are not necessarily unlinkable, either to
the Provider, or to a network observer.  If the goal is unlinkability,
unauthenticated sessions are probably necessary but not sufficient.
It's important that the draft be clear about this.

          --dkg