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

From: Daniel Migault <[email-masked]>
Date: Sun, 18 Jan 2015 22:49:34 +0100

Dear Friends an Colleagues,

This is the Working Group Last Call (WGLC) for draft-ietf-tzdist-service-05
[1] <http://tools.ietf.org/html/draft-ietf-tzdist-service-05>. Please
provide all comments by February 2.

Best Regards,

Daniel and Eliot

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

On Sat, Jan 17, 2015 at 6:52 PM, Lester Caine <[email-masked]> wrote:

> Looking good!
>
> Question ... Any reason why 'opaque token' would not be simply the
> version? Since the data is locked to it's version number nothing else
> should exist.
>
> Only problem ...
> I'm still unconvinced by the attempt to create "monolithic" and
> "incremental" models! If I am publishing an historic snapshot, I need a
> complete set of timezones for that version ... even if my publication
> method is only supplying the incremental changes. It is an
> implementation detail of the storage process and asking for an
> 'incremental' version just seems wrong. One needs the 'monolithic'
> version at that point. If my data source is TZ, then the only version
> numbers are those provided by the 'monolithic' view, but I only notify
> the incremental changes.
>
> --
> 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
>
> _______________________________________________
> Tzdist mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist
>

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

---

From: Daniel Migault <[email-masked]>
Date: Sun, 18 Jan 2015 22:53:15 +0100

I have read the document and it mostly look fine to me. In addition to
Lester's comments here are my personal comments:

comment 1:

Introduction section 1

"""In the case of operating systems, often those changes only get
propagated to client machines when there is an operating system update,
which can be infrequent, resulting in inaccurate time zone data being
present for significant amounts of time."""

One could also add that relying on OS updates are more risky operations
than TZ updates, as such, we should not rely on OS upgrade for TZ updates.

comment 2:

Figure 1. Maybe  "Provider" could be replaced by "Root
Providers"/"Secondary Providers"

comment 3:

"""3.5. Observance
   Data that defines a portion of a time zone where the UTC offset is a
constant.
"""
The offset is always a constant, so I am wondering if it would not be
better to say:

Data that defines a portion of a time zone where the UTC offset is constant
during the observance.

comment 4:

"""To support conditional time zone requests, based on whether the
underlying time zone data or meta-data has changed, the server supports two
options:"""

I would prefer to make clear these two options are necessary to cover all
cases. Maybe removing "the server supports two options" could leverage the
idea that the two options are simply two ways to do the same thing. The
next paragraph however clarify this.

comment 5:

"""4.2.2.1. Initial Synchronization of All Time Zones

   When a secondary service or a client wishing to cache all time zone data
first starts, or wishes to do a full refresh, it synchronizes with another
server by first issuing a "list" action.  """

maybe it would help the reader ti briefly indicate what a list action
results in.

Note that this is done in section
4.2.2.3. "[...]"list" action to retrieve all the time zone meta-data [...]"

comment 6:
4.2.2.2. Subsequent Synchronization of All Time Zones

s/etag/ETag/ ?

OK, I got it. Personaly, I would prefer another keyword for etag,
(tz_version?) and then saying its value equals ETag. But that is only a
personal opinion.

comment 7:

"""4.2.2.2. Subsequent Synchronization of All Time Zones

   A secondary service or a client caching all time zones needs to
periodically synchronize with a server.  To do so it would issue a "list"
action with the "changedsince" URI query parameter set to the
   value of the opaque token returned by the last synchronization."""

Maybe it would ease if the response returned by the server is a bit more
detailed.

comment 8:

I would like to make sure the Json description will not cause any issue.

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

---

From: Lester Caine <[email-masked]>
Date: Sun, 18 Jan 2015 22:23:04 +0000

> than TZ updates, as such, we should not rely on OS upgrade for TZ updates.

While I have indicated my own preference, I probably have not explained
what I'm thinking as a base for this. Currently the data distributed via
the OS process is not reliably identified, and that what IS needed is a
clean and verifiable publisher. Once tz_dist established that base, then
it would be preferable if the OS updates cloned a tz_dist source -
Including the historic updates - and then this base can be updated by
access to that data directly.

All of the key elements are present in draft 05, provided that 'opaque
token' is actually the version supplied by the OS. Then
'list->changedsince' will provide a clean incremental update process via
the matching publisher.

---

From: Ken Murchison <[email-masked]>
Date: Fri, 23 Jan 2015 13:30:53 -0500

The document looks good to me, but here are a few nits:

Section 5.2: Since the text now states that an incorrect/unknown 
changedsince parameter is to be ignored, the 
urn:ietf:params:tzdist:error:invalid-changedsince error code should only 
be used if changedsince is used more than once

Section 6.4.  If we are going to just a use date value rather than a 
full UTC date-time, the RFC 3339 construct that we are using is "full-date"

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Daniel Migault <[email-masked]>
Date: Sun, 25 Jan 2015 21:33:44 +0100

Dear  Friends and Colleagues,

Thank you for providing feed backs. We are almost half way the WGLC period,
and I hope we can get more feed back, so please provide you comments by
February 2.

BR,
Daniel and Eliot

On Fri, Jan 23, 2015 at 7:30 PM, Ken Murchison <[email-masked]> wrote:

> changedsince parameter is to be ignored, the urn:ietf:params:tzdist:error:invalid-changedsince
> error code should only be used if changedsince is used more than once
>
> Section 6.4.  If we are going to just a use date value rather than a full
> UTC date-time, the RFC 3339 construct that we are using is "full-date"
>
> --
> Kenneth Murchison

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

---

From: Stephen Colebourne <[email-masked]>
Date: Sun, 25 Jan 2015 23:13:24 +0000

Some minor points:

Typo:
Section 4.1
"The interactions with the HTTP server can be broken down into a set
"actions" that define the overall function being requested "
needs "of" between "set" and "actions".

Section 5.2.1
"In this example the client requests the time zone identifiers and in
addition requests that the US-English local names be returned."
No such local-name request appears in the example.

Section 5.4.1, 5.5.1
Example request URLs are malformed (no "?")

While I didn't read every last word, I think the draft is ready to move forward.

Stephen

On 18 January 2015 at 21:49, Daniel Migault <[email-masked]> wrote:
> [1]. Please provide all comments by February 2.
>
> Best Regards,
>
> Daniel and Eliot
>
>

---

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

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

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

---

From: Lester Caine <[email-masked]>
Date: Wed, 28 Jan 2015 20:07:32 +0000

On 28/01/15 19:24, Daniel Migault wrote:
> <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.

My questions posted earlier still remains unanswered ... I think we are
basically there except for strangeness this extra 'mode' introduces.

---

From: Doug Royer <[email-masked]>
Date: Wed, 28 Jan 2015 13:14:46 -0700

My needs are simple. It looks great to me. I have not started 
implementing, so there may be nits that I have not spotted. As there are 
others that are implementing, I suspect if there are any, they will be 
found.

Great Job!  I am always amazed how much work you guys put into making 
our lives easier!

Thanks!

On 01/25/2015 01:33 PM, Daniel Migault wrote:
> Thank you for providing feed backs. We are almost half way the WGLC 
> period, and I hope we can get more feed back, so please provide you 
> comments by February 2.

-- 

Doug Royer - (http://K7DMR.us / http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 28 Jan 2015 12:20:02 -0800

Hi Lester,

> basically there except for strangeness this extra 'mode' introduces.

FYI Mike and myself (Ken too) are at the CalConnect meeting this week so we 
won't be able to provide timely responses. I'll try and get to all the 
posted issues on Monday.

-- 
Cyrus Daboo

---

From: Eliot Lear <[email-masked]>
Date: Wed, 28 Jan 2015 21:56:04 +0100

<Chair hat off>

We had discussed supporting raw TZ database zone files as a new media
type.  As a last call comment, I'd like to know if there is support for
that and whether anyone would be willing to implement?

Eliot

On 1/18/15 10:49 PM, Daniel Migault wrote:
> This is the Working Group Last Call (WGLC) for
> draft-ietf-tzdist-service-05 [1]
> <http://tools.ietf.org/html/draft-ietf-tzdist-service-05>. Please
> On Sat, Jan 17, 2015 at 6:52 PM, Lester Caine <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Looking good!
>
>     [email-masked] <mailto:[email-masked]>

---

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

On 1/30/15 3:13 AM, Daniel Kahn Gillmor wrote:
> Hi Daniel and Elliot--
>
> On Wed 2015-01-28 14:24:28 -0500, Daniel Migault wrote:
>  [...]
> 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 08:05:51 +0100

Just following up on my own email, the working group is advised to take
quite seriously privacy considerations.  As Daniel referenced RFC 6973,
even though we considered some of these issues, I refer you to an
article in today's Wall Street Journal[1] that highlights how easy it is
to correlate information to individuals and how important a role
location plays into that.

Eliot
[1]
http://www.wsj.com/articles/metadata-can-expose-persons-identity-even-when-name-isnt-1422558349?mod=WSJ_hp_EditorsPicks

On 1/30/15 6:24 AM, Eliot Lear wrote:
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

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

Hi Daniel and Elliot--

 [...]

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

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

 

            --dkg

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 30 Jan 2015 08:39:33 -0800

Hi Eliot,

> location plays into that.

Whilst that is true I don't think we should be required to deal with issues 
that are generic to HTTP itself (and in some cases already covered in the 
base HTTP specs - e.g. server log information). Once I get a chance to look 
over Daniel's comments in depth (and a big thank you to him for taking the 
time to do a through analysis), I will try and propose some text for a 
Privacy Considerations section - the first statement in that will be a 
reference to the various sections in the 7230-7234 document suite that are 
relevant. There will be issues specific to tzdist that we definitely need 
to address.

-- 
Cyrus Daboo

---

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

> but what are the privacy implications if you have a system service that

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

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

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.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 30 Jan 2015 19:40:45 +0000

Hi Cyrus,

On 30/01/15 16:39, Cyrus Daboo wrote:
>>
> 
> Whilst that is true I don't think we should be required to deal with
> issues that are generic to HTTP itself (and in some cases already
> covered in the base HTTP specs - e.g. server log information). 

I think that's fair, but could you also watch out to see if
there is (or is not) a 3rd category of issue which isn't
generic to HTTP or covered in HTTP specs but is also not
specific to tzdist? What I mean is that there could be
things identified here that would affect some but not all
protocols layered on HTTP. For example, it could be that using
HTTP at startup or periodically to make the same requests
causes some issue(s) that fall into this category. Another
way to think about this category would be things that you
don't want to put in the tzdist spec but that you also don't
think the httpbis WG would have agreed to put into the base
HTTP spec.

Regardless of whether or not those end up documented in
tzdist, noting them and that they're of this nature could
be useful.

> Once I
> get a chance to look over Daniel's comments in depth (and a big thank
> you to him for taking the time to do a through analysis), I will try and
> propose some text for a Privacy Considerations section - the first
> statement in that will be a reference to the various sections in the
> 7230-7234 document suite that are relevant. There will be issues
> specific to tzdist that we definitely need to address.

It is a really excellent review, yes.

Cheers,
S.

---

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

Thanks for the response, Cyrus!

On Fri 2015-01-30 11:39:33 -0500, Cyrus Daboo wrote:
> base HTTP specs - e.g. server log information).

I'm not convinced by this argument.  This proposal sets up a particular
profile that an HTTP server is likely to run, with clients that are
going to access it in a very particular pattern under normal
circumstances.

As a result, we can characterize the expected system behavior in much
more detailed ways, so we can think more concretely about how and why
logs (and other aspects of HTTP operation) might be useful or harmful.

For example, the spec already says that the server needs to be
configured to work with HTTPS.  that's distinct from many HTTP server
configurations in the wild, and with good reason.  Why doesn't this
apply to other aspects of HTTP operation like logging?

(side note: i just noticed, do you want to require the clients to use
HTTPS with the SNI extension of TLS?  If you do make that a requirement,
it would make it easier for Providers to deploy their systems on shared
IP addresses)

   --dkg

---

From: Daniel Migault <[email-masked]>
Date: Fri, 30 Jan 2015 21:18:09 +0100

Best Regards,

Daniel and Eliot

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

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

---

From: Lester Caine <[email-masked]>
Date: Fri, 30 Jan 2015 23:01:33 +0000

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

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

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

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

---

From: Paul Eggert <[email-masked]>
Date: Fri, 30 Jan 2015 16:53:53 -0800

Cyrus Daboo wrote:
> I will try and propose some text for a Privacy Considerations section

Although we will need such a section, the tzdist privacy issues dkg raised 
shouldn't be addressed merely by adding a section that says in essence, "yes, 
admittedly tzdist's privacy stinks, but at least we've clearly documented that 
it stinks".  Let's instead use his helpful review to adjust the protocol so that 
it better preserves privacy.

Doing that will take some work, but it's doable.  Here are a couple of thoughts 
in that direction.

First, we can prevent servers from tracking users via ETag or steganographic 
data by requiring standard ETags (e.g., "tz2015a") and normalized data.  Yes, 
this is a bit harder to implement on the server side, but it's not *that* hard, 
and it does prevent this privacy abuse.

Second, we can prevent tracking users via query parameters by making the typical 
query be simply "Give me everything", thus avoiding the parameters.  As the 
entire tz database can be communicated in 25 kB in compressed format, this will 
be reasonably efficient (when combined with standard ETags) and will better 
preserve privacy.  Yes, this also requires more work (on both client and server 
side), but it's not that much work, and if we really want privacy it should be 
work we're willing to do.

---

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

--dkg

---

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

---

From: Lester Caine <[email-masked]>
Date: Sat, 31 Jan 2015 23:37:23 +0000

On 31/01/15 22:34, Paul Eggert wrote:
> 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.

We are talking about a type of processor with 32k bytes of ROM, the
majority of which is already populated by the TCP stack and other
software needed simply to provide the very basic network interface. Of
cause one can dictate that tzdist is only usable on larger devices but
we are talking about devices that are being built to a price and any
unnecessary excess gets trimmed. Yes the device can simply throw
everything it does not need away, but that still requires it to handle
all of the tzdist data stack rather than just a simple extract for the
next year of a single TZ.

What is perhaps amazing here is that the first controllers I designed
had just 1024 words of ROM but provided a 2/5 weekly cycle timer, and
nothing much has changed in that area in 30 years.