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

From: Daniel Migault <[email-masked]>
Date: Wed, 28 Jan 2015 20:24:28 +0100

Dear Friends and Colleagues,

Our document describing Time Zone Data Distribution Service
<http://tools.ietf.org/html/draft-ietf-tzdist-service-05> [1] is close to
be finalized and we would like to proceed to cross area review.

We would greatly appreciate to get review by February 11.

Best Regards,

Daniel and Eliot

[1] http://tools.ietf.org/html/draft-ietf-tzdist-service-05

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 29 Jan 2015 21:13:36 -0500

Hi Daniel and Elliot--

> We would greatly appreciate to get review by February 11.
 [...]
> [1] http://tools.ietf.org/html/draft-ietf-tzdist-service-05

Thanks for your work on this.  This is the first time i've seen this
draft; apologies for not looking at it earlier.

I'm only subscribed to [email-masked] (and ietf-privacy, which is idle
lately, but i've included here because some of my review touches on
privacy), so this post might not make it through to [email-masked] --
feel free to forward it as needed.

I did a quick skim here with my security and privacy hats on, and have a
few comments:

(privacy) Privacy Considerations section is missing
===================================================

There is *no* "Privacy Considerations" section in the draft at all.
Please read RFC 6973 for guidance in conducting a privacy review of the
protocol.  The act of querying these servers leaks something about the
location of the person doing the query, at least, and may leak
information about other locations that they're interested in.  It's also
possible that regular attempts to query this information will provide a
linkable trail of the user, which could then be (mis)used without their
knowledge or permission.

Here's an attempt at a quick analysis, though i haven't thought through
the protocol in detail.  I hope you'll do your own analysis, and you're
welcome to take any of mine:

Implausibly: if the average user is interested in 5 timezones, and there
are 774 known zones ("find /usr/share/zoneinfo -type f | wc"), and those
interests were evenly distributed across the zones for every users, then
the set of requests to update an individual's preferred timezones yields
nearly 50 bits of entropy, far more than enough to distinguish every
individual human from each other.

More plausibly: timezone interest is probably less than 5 for most
people, and it isn't evenly distributed: the people who are interested
in Americas/New_York are more likely to be interested in
Americas/Los_Angeles than in Arctic/Longyearbyen.  But anyone with an
unusual set of TZs can probably be identified (perhaps uniquely) by any
provider they talk to just by what TZs they ask for.

Since §4.1.4 says "Clients SHOULD poll for changes, using an appropriate
conditional request, at least once a day", a malicious provider intent
on surveilling its users and with a mechanism to do so would have a
daily checkin.  I imagine this as some kind of background system service
looking for updates.  the daily checkin could be used to track a user's
movements around the network, if their device is not stationary.  The
time of checkin could also be used as a linking mechanism, if the
machine polls with rigid regularity.

Are there strategies that someone interested in preserving their
anonymity from a tzdata provider should take to remain anonymous?  If
so, what are they?

(privacy) HTTP pipelining?
==========================

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?

(privacy) HTTP Cookies?
=======================

The choice of HTTP transport also allows for servers to set cookies in
clients -- should clients accept and re-transmit cookies from the
server?  What are the privacy implications?

(privacy) Tracking via ETag?
============================

Also, conditional requests seem to be encouraged via the use of an ETag
header.  It looks to me like a provider who wants to track its users
individually (even in the absence of cookies) could use a cache of
personalized ETags to do so.

For example, the first time any client requests TZ X (with no
If-None-Match request header), the server mints a new ETag Y, generates
a new client ID Z, and records:

 * Client ID Z
 * the requested TZ X
 * the new ETag Y
 * the time of issuance
 * the IP address
 * any other interesting metadata

When a request comes in for TZ X with an If-None-Match: Y header, the
server can link the two requests and record them both with client ID Z.

When the underlying data for the TZ actually changes, the server mints a
new ETag (for the new version of TZ X), but associates it with the same
client ID Z.

(privacy) Logging policy for distribution servers?
==================================================

There is also no mention of recommended logging policy for the servers,
no attempt to address data minimization or the risks to trackable users
based on normal server logs.

(privacy) Authenticated clients are trackable
=============================================

the Security Considerations section says:

   Servers MAY require some form of authentication or authorization of
   clients (including secondary servers) to restrict which clients are
   allowed to access their service, or provide better identification of
   errant clients.  As such, servers MAY require HTTP- based
   authentication as per [RFC7235].

Clients who make authenticated connections to servers are eminently
trackable by those servers.  What are the privacy implications for those
clients?

(privacy) network observers tracking clients
============================================

Someone passively observing the network could also potentially track the
clients of a given server via traffic analysis, even if the server is
not cooperating.  First, the attacker could get a stash of all the data
that the server has, noting the size of each zone under each supported
format.

When a new request is made for a zone, the attacker can observe the size
of the query and the size of the response and guess with high
probability which zone was requested.

If the clients poll once a day on a schedule (i.e. exactly every 86400
seconds) then the network observer may be able to track updates and
determine when a client interested in a particular zone does an update.

What mechanisms could a client (and server?) use to frustrate such a
network-based attacker to keep a given client's identity anonymous?

(security/privacy) HTTP redirection
====================================

What if the server sends an HTTP redirection (e.g. via HTTP response 301
or 302) --  should the client follow it?  What if it is to a cleartext
HTTP resource?  What are the security and privacy consequences of
following these redirections off-origin?

(security) Consequences of accepting bad TZ updates?
====================================================

I'm glad that the Security Considerations recognizes that reliable TZ
data is vital -- but no example is given of what a data compromise might
look like.  Is it worth providing a couple of examples of bad outcomes?
are we talking about missed appointments?  or crashing software?  or
something else?

(security) why not require TLS on both sides?
=============================================

you've got that the service MUST operate over https, but the clients
only SHOULD try https first.  Why allow for cleartext access at all?
Why not say that both clients and servers MUST support HTTPS?

I see https://tools.ietf.org/wg/tzdist/trac/ticket/7 suggests that there
is consensus that you don't want "mandatory to use", but i don't know
where the discussion is, or why you don't want it.

(security) Provider-to-Provider TLS
===================================

Connections between "Secondary Providers" and "Root Providers" seem
different from the connections between Clients and Providers.  If you
can't mandate HTTPS for all clients for some reason, what about at least
mandating that the caching infrastructure requires TLS for all
provider-to-provider connections?  The secondary provider will need a
TLS stack anyway (as a server), so it should be able to do TLS on the
upstream side.

(security) DNS compromise leaves only cleartext
===============================================

If a network-based attacker can filter network traffic, they can simply
drop all outbound _timezones._tcp.example.com DNS queries, and then when
the client gives up, they can allow through (or provide their own, if
DNSSEC isn't involved) responses to _timezone._tcp.example.com.

This immediately puts the network attacker in the position of being able
to dictate timezone information to a client willing to fall back to
cleartext.

(security) no-DNSSEC fallback checks are ambiguous
==================================================

The Security Considerations currently say:

   In the absence of a secure DNS option, clients SHOULD check that the
   target FQDN returned in the SRV record matches the original service
   domain that was queried.  If the target FQDN is not in the queried
   domain, clients SHOULD verify with the user that the SRV target FQDN
   is suitable for use before executing any connections to the host.

What does "matches" mean here?  the second sentence suggests that it
means "shares some sort of a suffix with" -- but which part?  If i query
for an SRV of _timezones._tcp.tz.example.com, and it replies with an
FQDN of bar.example.com, is that OK?  what about x.y.z.bar.example.com?
If DNSSEC isn't available, the attacker can still point this response to
any IP address of their choice, right?

What does "verify with the user" mean if this is a TZdata service, which
is presumably running automatically on the computer to keep this
information up-to-date?  most such services have no user interaction at
all.

If there is a UI, what options would the user be given in such a case?
Is this a popup dialog box that says "you asked for timezone data
updates from tz.example.com -- is it ok to get it from whatever.example
instead?"  What users can make sense of this dialog?  What information
would a fully-technically-cognizant user (a deep wizard) use to answer
it sensibly?  What would a normal user use?

If DNSSEC *is* available, is it OK if the record points outside the
zone?  what if it points to a non-signed zone?

(security) Conflicts between Providers?
========================================

The draft implies that a client might fetch data from multiple
providers.  What should the client do if two providers provide
conflicting information about the same TZ?

(security) use examples of certificate validation
==================================================

The combination of SRV records and X.509 certificate validation and
(maybe) DNSSEC is a tricky subject.  you've referenced RFC 6125, but i
don't think that's enough.

Do you mean to suggest that the certificate should use a SRVName
subjectAltName (RFC4985)?  or should it use a DNSName subjectAltName
with the name sent in the SRV query?  or a DNSName subjectAltName
with the FQDN returned in the SRV response?

Providing an example would make it clearer what you mean.  For example:
 
   If a client looks up SRV for _timezones._tcp.example.com, and gets a
   response of tz.example.net, then the certificate should (a) be valid,
   and (b) have either a subjectAltName DNSName of tz.example.net or a
   subjectAltName SRVName of _timezones._tcp.example.com (or both).

(please adjust to taste, i don't mean to tell you what the right choice
is here, it's an ugly problem)

(security) Statically-signed data vs. transport security
========================================================

The security of the transmission process seems to rely entirely on
transport security.

If there is a compromise in transmission between the Root provider and
the secondary provider, or a compromise of any provider, the client has
no way of knowing that they're getting bad data.

tzdata changes infrequently enough that it seems like it could be signed
with an offline key, making compromise of running systems much less
fruitful.  But this only works if the client can verify the offline
signature.

Have you considered any mechanism that the client could use to verify
the tz update based on data itself, without depending solely on
transport security?

I see this question tangentially raise here:

  https://www.ietf.org/mail-archive/web/tzdist/current/msg00102.html

but it's answered only in the "we still need TLS" way (which i agree
with).  Is any work done (or planned) on providing signed/verifiable
data?

(security) TLS best-practices?
===============================

I'm glad that you've got TLS as a MUST for servers.  Is it worth making
a normative reference to the UTA's TLS best-practices document?

  https://tools.ietf.org/html/draft-ietf-uta-tls-bcp

Sorry this got long, and that this is more in the form of questions than
patches.  I hope i haven't repeated too much of what the tzdist WG has
already discussed -- please feel free to point me to relevant
discussions that i may have missed.

            --dkg

---

From: Eliot Lear <[email-masked]>
Date: Fri, 30 Jan 2015 06:24:59 +0100

Thank you Daniel for your prompt review.  The working group and draft
editor shall address your comments prior to advancing this document. 
N.B., some discussion has already occurred in this area, even though it
is not covered in the draft.

Eliot

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 30 Jan 2015 16:20:48 -0500

On Fri 2015-01-30 12:57:29 -0500, Lester Caine wrote:
> On 30/01/15 02:13, Daniel Kahn Gillmor wrote:
> 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?

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

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.

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

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

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?

        --dkg

---

From: Eliot Lear <[email-masked]>
Date: Sat, 31 Jan 2015 13:08:26 +0100

Hi Daniel,

Thanks again for this review.

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

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

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.

Eliot

---

From: Paul Eggert <[email-masked]>
Date: Sat, 31 Jan 2015 00:15:15 -0800

> that don't already have such a mechanism.

My impression is that the tzdist protocol is also intended to supplement those 
operating system updates, or in the long run to replace them.  In practice these 
OS updates are sometimes delayed or deferred, and I think the hope is partly 
that such problems would occur less often with tzdist.

Privacy ought to easier for this usage of tzdist, as network observers shouldn't 
be able to learn more about full tzdata updates than they can for any other OS 
update.

> Consider an internet-connected bedside alarm clock

Given your comments, I'd think that any such alarm clock should get the entire 
tz database, just as an OS update would.  This would preserve privacy better 
than having the alarm clock query only about updates to America/Los_Angeles and 
Europe/Paris.

---

From: Lester Caine <[email-masked]>
Date: Fri, 30 Jan 2015 17:57:29 +0000

-- 
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: Lester Caine <[email-masked]>
Date: Fri, 30 Jan 2015 23:01:33 +0000

> are clearly distinct, with different implications?  Can we identify

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?

> treat TZ data the same way that they treat other system updates.  Is

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.

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

> something that would have serious privacy implications, if their queries

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

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

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

---

From: Lester Caine <[email-masked]>
Date: Sat, 31 Jan 2015 09:17:39 +0000

On 31/01/15 08:15, Paul Eggert wrote:
> Given your comments, I'd think that any such alarm clock should get the
> entire tz database, just as an OS update would.  This would preserve
> privacy better than having the alarm clock query only about updates to
> America/Los_Angeles and Europe/Paris.

As already stated, some devices such as central heating controllers
would not need a processor capable of the sort of processing power
needed to handle that, but would benefit immensely simply from switching
DST setting at the right time. If that needs a 'son of tzdist'
specification then OK but it's those sorts of devices that the 'NOT'
requirements of the charter are directly addressing?

Given that the sort of processing power available today is probably
making that a thin argument, but a substantial number of 'internet
ready' processors do not have a large spare storage capacity even given
how small the TZ database can be compacted ( and don't have leap-second
capable clocks ;) ) many of these are already active on the internet.

---

From: Paul Eggert <[email-masked]>
Date: Sat, 31 Jan 2015 14:34:46 -0800

Lester Caine wrote:

> some devices such as central heating controllers
> 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.