Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   None   Next  Group: TZDIST

RFC 7808

Time Zone Data Distribution Service

Pages: 56
Proposed STD
Part 3 of 3 – Pages 42 to 56
First   Prev   None

Top   ToC   Page 42   prevText
8.  Security Considerations

   Time zone data is critical in determining local or UTC time for
   devices and in calendaring and scheduling operations.  As such, it is
   vital that a reliable source of time zone data is used.  Servers
   providing a time zone data distribution service MUST support HTTP
   over Transport Layer Security (TLS) (as defined by [RFC2818] and
   [RFC5246], with best practices described in [RFC7525]).  Servers MAY
   support a time zone data distribution service over HTTP without TLS.
   However, secondary servers MUST use TLS to fetch data from a primary

   Clients SHOULD use Transport Layer Security as defined by [RFC2818],
   unless they are specifically configured otherwise.  Clients that have
   been configured to use the TLS-based service MUST NOT fall back to
   using the non-TLS service if the TLS-based service is not available.
   In addition, clients MUST NOT follow HTTP redirect requests from a
   TLS service to a non-TLS service.  When using TLS, clients MUST
   verify the identity of the server, using a standard, secure mechanism
   such as the certificate verification process specified in [RFC6125]
   or DANE [RFC6698].

   A malicious attacker with access to the DNS server data, or able to
   get spoofed answers cached in a recursive resolver, can potentially
   cause clients to connect to any server chosen by the attacker.  In
   the absence of a secure DNS option, clients SHOULD check that the
   target FQDN returned in the SRV record is the same as the original
   service domain that was queried, or is a sub-domain of the original
   service domain.  In many cases, the client configuration is likely to
   be handled automatically without any user input; as such, any
   mismatch between the original service domain and the target FQDN is
   treated as a failure and the client MUST NOT attempt to connect to
   the target server.  In addition, when Transport Layer Security is
   being used, the Transport Layer Security certificate SHOULD include
   an SRV-ID field as per [RFC4985] matching the expected DNS SRV
   queries clients will use for service discovery.  If an SRV-ID field
   is present in a certificate, clients MUST match the SRV-ID value with
   the service type and domain that matches the DNS SRV request made by
   the client to discover the service.

   Time zone data servers SHOULD protect themselves against poorly
   implemented or malicious clients by throttling high request rates or
   frequent requests for large amounts of data.  Clients can avoid being
   throttled by using the polling capabilities outlined in
   Section 4.1.4.  Servers MAY require some form of authentication or
   authorization of clients (including secondary servers), as per
   [RFC7235], to restrict which clients are allowed to access their
   service or provide better identification of problematic clients.
Top   ToC   Page 43
9.  Privacy Considerations

   The type and pattern of requests that a client makes can be used to
   "fingerprint" specific clients or devices and thus potentially used
   to track information about what the users of the clients might be
   doing.  In particular, a client that only downloads time zone data on
   an as-needed basis, will leak the fact that a user's device has moved
   from one time zone to another or that the user is receiving
   scheduling messages from another user in a different time zone.

   Clients need to be aware of the potential ways in which an untrusted
   server or a network observer might be able to track them and take
   precautions such as the following:

   1.  Always use TLS to connect to the server.

   2.  Avoid use of TLS session resumption.

   3.  Always fetch and synchronize the entire set of time zone data to
       avoid leaking information about which time zones are actually in
       use by the client.

   4.  Randomize the order in which individual time zones are fetched
       using the "get" action, when retrieving a set of time zones based
       on a "list" action response.

   5.  Avoid use of conditional HTTP requests [RFC7232] with the "get"
       action to prevent tracking of clients by servers generating
       client-specific ETag header field values.

   6.  Avoid use of cookies in HTTP requests [RFC6265].

   7.  Avoid use of authenticated HTTP requests.

   8.  When doing periodic polling to check for updates, apply a random
       (positive or negative) offset to the next poll time to avoid
       servers being able to identify the client by the specific
       periodicity of its polling behavior.

   9.  A server trying to "fingerprint" clients might insert a "fake"
       time zone into the time zone data, using a unique identifier for
       each client making a request.  The server can then watch for
       client requests that refer to that "fake" time zone and thus
       track the activity of each client.  It is hard for clients to
       identify a "fake" time zone given that new time zones are added
       occasionally.  One option to mitigate this would be for the
       client to make use of two time zone data distribution servers
       from two independent providers that provide time zone data from
Top   ToC   Page 44
       the same publisher.  The client can then compare the list of time
       zones from each server (assuming they both have the same version
       of time zone data from the common publisher) and detect ones that
       appear to be added on one server and not the other.
       Alternatively, the client can check the publisher data directly
       to verify that time zones match the set the publisher has.

   Note that some of the above recommendations will result in less
   efficient use of the protocol due to fetching data that might not be
   relevant to the client.

   An organization can set up a secondary server within their own domain
   and configure their clients to use that server to protect the
   organization's users from the possibility of being tracked by an
   untrusted time zone data distribution server.  Clients can then use
   more-efficient protocol interactions, free from the concerns above,
   on the basis that their organization's server is trusted.  When doing
   this, the secondary server would follow the recommendations for
   clients (listed in the previous paragraph) so that the untrusted
   server is not able to gain information about the organization as a
   whole.  Note, however, that client requests to the secondary server
   are subject to tracking by a network observer, so clients ought to
   apply some of the randomization techniques from the list above.

   Servers that want to avoid accidentally storing information that
   could be used to identify clients can take the following precautions:

   1.  Avoid logging client request activity, or anonymize information
       in any logs (e.g., client IP address, client user-agent details,
       authentication credentials, etc.).

   2.  Add an unused HTTP response header to each response with a random
       amount of data in it (e.g., to pad the overall request size to
       the nearest power-of-2 or 128-byte boundary) to avoid exposing
       which time zones are being fetched when TLS is being used, via
       network traffic analysis.

10.  IANA Considerations

   This specification defines a new registry of "actions" for the time
   zone data distribution service protocol, defines a "well-known" URI
   using the registration procedure and template from Section 5.1 of
   [RFC5785], creates two new SRV service label aliases, and defines one
   new iCalendar property parameter as per the registration procedure in
   [RFC5545].  It also adds a new "TZDIST Identifiers Registry" to the
   IETF parameters URN sub-namespace as per [RFC3553] for use with
   protocol related error codes.
Top   ToC   Page 45
10.1.  Service Actions Registration

   IANA has created a new top-level category called "Time Zone Data
   Distribution Service (TZDIST) Parameters" and has put all the
   registries created herein into that category.

   IANA has created a new registry called "TZDIST Service Actions", as
   defined below.

10.1.1.  Service Actions Registration Procedure

   This registry uses the "Specification Required" policy defined in
   [RFC5226], which makes use of a designated expert to review potential

   The IETF has created a mailing list,, which
   is used for public discussion of time zone data distribution service
   actions proposals prior to registration.  The IESG has appointed a
   designated expert who will monitor the
   mailing list and review registrations.

   A Standards Track RFC is REQUIRED for changes to actions previously
   documented in a Standards Track RFC; otherwise, any public
   specification that satisfies the requirements of [RFC5226] is

   The registration procedure begins when a completed registration
   template, as defined below, is sent to and  The designated expert is expected to tell IANA and
   the submitter of the registration whether the registration is
   approved, approved with minor changes, or rejected with cause, within
   two weeks.  When a registration is rejected with cause, it can be
   resubmitted if the concerns listed in the cause are addressed.
   Decisions made by the designated expert can be appealed as per
   Section 7 of [RFC5226].

   The designated expert MUST take the following requirements into
   account when reviewing the registration:

   1.  A valid registration template MUST be provided by the submitter,
       with a clear description of what the action does.

   2.  A proposed new action name MUST NOT conflict with any existing
       registered action name.  A conflict includes a name that
       duplicates an existing one or that appears to be very similar to
       an existing one and could be a potential source of confusion.
Top   ToC   Page 46
   3.  A proposed new action MUST NOT exactly duplicate the
       functionality of any existing actions.  In cases where the new
       action functionality is very close to an existing action, the
       designated expert SHOULD clarify whether the submitter is aware
       of the existing action, and has an adequate reason for creating a
       new action with slight differences from an existing one.

   4.  If a proposed action is an extension to an existing action, the
       changes MUST NOT conflict with the intent of the existing action,
       or in a way that could cause interoperability problems for
       existing deployments of the protocol.

   The IANA registry contains the name of the action ("Action Name") and
   a reference to the section of the specification where the action
   registration template is defined ("Reference").

10.1.2.  Registration Template for Actions

   An action is defined by completing the following template.

   Name:  The name of the action.

   Request-URI Template:  The URI template used in HTTP requests for the

   Description:  A general description of the action, its purpose, etc.

   Parameters:  A list of allowed request URI query parameters,
      indicating whether they are "REQUIRED" or "OPTIONAL" and whether
      they can occur only once or multiple times, together with the
      expected format of the parameter values.

   Response:  The nature of the response to the HTTP request, e.g., what
      format the response data is in.

   Possible Error Codes:  Possible error codes reported in a JSON
      "problem details" object if an HTTP request fails.
Top   ToC   Page 47
10.1.3.  Actions Registry

   The following table provides the initial content of the actions

                | Action Name   | Reference              |
                | capabilities  | RFC 7808, Section 5.1  |
                | list          | RFC 7808, Section 5.2  |
                | get           | RFC 7808, Section 5.3  |
                | expand        | RFC 7808, Section 5.4  |
                | find          | RFC 7808, Section 5.5  |
                | leapseconds   | RFC 7808, Section 5.6  |

10.2.  timezone Well-Known URI Registration

   IANA has added the following to the "Well-Known URIs" [RFC5785]

   URI suffix:  timezone

   Change controller:  IESG.

   Specification document(s):  RFC 7808

   Related information:  None.

10.3.  Service Name Registrations

   IANA has added two new service names to the "Service Name and
   Transport Protocol Port Number Registry" [RFC6335], as defined below.

10.3.1.  timezone Service Name Registration

   Service Name:  timezone

   Transport Protocol(s):  TCP

   Assignee:  IESG <>

   Contact:  IETF Chair <>

   Description:  Time Zone Data Distribution Service - non-TLS

   Reference:  RFC 7808
Top   ToC   Page 48
   Assignment Note:  This is an extension of the http service.  Defined
      TXT keys: path=<context path> (as per Section 6 of [RFC6763]).

10.3.2.  timezones Service Name Registration

   Service Name:  timezones

   Transport Protocol(s):  TCP

   Assignee:  IESG <>

   Contact:  IETF Chair <>

   Description:  Time Zone Data Distribution Service - over TLS

   Reference:  RFC 7808

   Assignment Note:  This is an extension of the https service.  Defined
      TXT keys: path=<context path> (as per Section 6 of [RFC6763]).

10.4.  TZDIST Identifiers Registry

   IANA has registered a new URN sub-namespace within the IETF URN Sub-
   namespace for Registered Protocol Parameter Identifiers defined in

   Registrations in this registry follow the "IETF Review" [RFC5226]

   Registry name:  TZDIST Identifiers

   URN prefix:  urn:ietf:params:tzdist

   Specification:  RFC 7808


   Index value:  Values in this registry are URNs or URN prefixes that
      start with the prefix "urn:ietf:params:tzdist:".  Each is
      registered independently.  The prefix
      "urn:ietf:params:tzdist:error:" is used to represent specific
      error codes within the protocol as defined in the list of actions
      in Section 5 and used in problem reports (Section 4.1.7).

   Each registration in the "TZDIST Identifiers" registry requires the
   following information:

   URN:  The complete URN that is used or the prefix for that URN.
Top   ToC   Page 49
   Description:  A summary description for the URN or URN prefix.

   Specification:  A reference to a specification describing the URN or
      URN prefix.

   Contact:  Email for the person or groups making the registration.

   Index Value:  As described in [RFC3553], URN prefixes that are
      registered include a description of how the URN is constructed.
      This is not applicable for specific URNs.

   The "TZDIST Identifiers" registry has the initial registrations
   included in the following sections.

10.4.1.  Registration of invalid-action Error URN

   The following URN has been registered in the "tzdist Identifiers"

   URN:  urn:ietf:params:tzdist:error:invalid-action

   Description:  Generic error code for any invalid action.

   Specification:  RFC 7808, Section 5


   Contact:  IESG <>

   Index value:  N/A.

10.4.2.  Registration of invalid-changedsince Error URN

   The following URN has been registered in the "tzdist Identifiers"

   URN:  urn:ietf:params:tzdist:error:invalid-changedsince

   Description:  Error code for incorrect use of the "changedsince" URI
      query parameter.

   Specification:  RFC 7808, Section 5.2


   Contact:  IESG <>

   Index value:  N/A.
Top   ToC   Page 50
10.4.3.  Registration of tzid-not-found Error URN

   The following URN has been registered in the "tzdist Identifiers"

   URN:  urn:ietf:params:tzdist:error:tzid-not-found

   Description:  Error code for missing time zone identifier.

   Specification:  RFC 7808, Sections 5.3 and 5.4


   Contact:  IESG <>

   Index value:  N/A.

10.4.4.  Registration of invalid-format Error URN

   The following URN has been registered in the "tzdist Identifiers"

   URN:  urn:ietf:params:tzdist:error:invalid-format

   Description:  Error code for unsupported HTTP Accept request header
      field value.

   Specification:  RFC 7808, Section 5.3


   Contact:  IESG <>

   Index value:  N/A.

10.4.5.  Registration of invalid-start Error URN

   The following URN has been registered in the "tzdist Identifiers"

   URN:  urn:ietf:params:tzdist:error:invalid-start

   Description:  Error code for incorrect use of the "start" URI query

   Specification:  RFC 7808, Sections 5.3 and 5.4

Top   ToC   Page 51
   Contact:  IESG <>

   Index value:  N/A.

10.4.6.  Registration of invalid-end Error URN

   The following URN has been registered in the "tzdist Identifiers"

   URN:  urn:ietf:params:tzdist:error:invalid-end

   Description:  Error code for incorrect use of the "end" URI query

   Specification:  RFC 7808, Sections 5.3 and 5.4


   Contact:  IESG <>

   Index value:  N/A.

10.4.7.  Registration of invalid-pattern Error URN

   The following URN has been registered in the "tzdist Identifiers"

   URN:  urn:ietf:params:tzdist:error:invalid-pattern

   Description:  Error code for incorrect use of the "pattern" URI query

   Specification:  RFC 7808, Section 5.5


   Contact:  IESG <>

   Index value:  N/A.
Top   ToC   Page 52
10.5.  iCalendar Property Registrations

   This document defines the following new iCalendar properties, which
   have been added to the "Properties" registry under "iCalendar Element
   Registries" [RFC5545]:

          | Property       | Status   | Reference              |
          | TZUNTIL        | Current  | RFC 7808, Section 7.1  |
          | TZID-ALIAS-OF  | Current  | RFC 7808, Section 7.2  |

11.  References

11.1.  Normative References

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              DOI 10.17487/RFC2046, November 1996,

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              DOI 10.17487/RFC2782, February 2000,

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
              DOI 10.17487/RFC2818, May 2000,

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,

   [RFC3553]  Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
              IETF URN Sub-namespace for Registered Protocol
              Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
              2003, <>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <>.
Top   ToC   Page 53
   [RFC4985]  Santesson, S., "Internet X.509 Public Key Infrastructure
              Subject Alternative Name for Expression of Service Name",
              RFC 4985, DOI 10.17487/RFC4985, August 2007,

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,

   [RFC5545]  Desruisseaux, B., Ed., "Internet Calendaring and
              Scheduling Core Object Specification (iCalendar)",
              RFC 5545, DOI 10.17487/RFC5545, September 2009,

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785,
              DOI 10.17487/RFC5785, April 2010,

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
              2011, <>.

   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
              DOI 10.17487/RFC6265, April 2011,

   [RFC6321]  Daboo, C., Douglass, M., and S. Lees, "xCal: The XML
              Format for iCalendar", RFC 6321, DOI 10.17487/RFC6321,
              August 2011, <>.
Top   ToC   Page 54
   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
              Cheshire, "Internet Assigned Numbers Authority (IANA)
              Procedures for the Management of the Service Name and
              Transport Protocol Port Number Registry", BCP 165,
              RFC 6335, DOI 10.17487/RFC6335, August 2011,

   [RFC6557]  Lear, E. and P. Eggert, "Procedures for Maintaining the
              Time Zone Database", BCP 175, RFC 6557,
              DOI 10.17487/RFC6557, February 2012,

   [RFC6570]  Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
              and D. Orchard, "URI Template", RFC 6570,
              DOI 10.17487/RFC6570, March 2012,

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
              2012, <>.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,

   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
              2014, <>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,

   [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
              DOI 10.17487/RFC7232, June 2014,
Top   ToC   Page 55
   [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
              RFC 7234, DOI 10.17487/RFC7234, June 2014,

   [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Authentication", RFC 7235,
              DOI 10.17487/RFC7235, June 2014,

   [RFC7265]  Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON
              Format for iCalendar", RFC 7265, DOI 10.17487/RFC7265, May
              2014, <>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <>.

   [RFC7807]  Nottingham, M. and E. Wilde, "Problem Details for HTTP
              APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016,

11.2.  Informative References

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, DOI 10.17487/RFC2131, March 1997,


   The authors would like to thank the members of the Calendaring and
   Scheduling Consortium's Time Zone Technical Committee, and the
   participants and chairs of the IETF tzdist working group.  In
   particular, the following individuals have made important
   contributions to this work: Steve Allen, Lester Caine, Stephen
   Colebourne, Tobias Conradi, Steve Crocker, Paul Eggert, Daniel Kahn
   Gillmor, John Haug, Ciny Joy, Bryan Keller, Barry Leiba, Andrew
   McMillan, Ken Murchison, Tim Parenti, Arnaud Quillaud, Jose Edvaldo
   Saraiva, and Dave Thewlis.

   This specification originated from work at the Calendaring and
   Scheduling Consortium, which has supported the development and
   testing of implementations of the specification.
Top   ToC   Page 56
Authors' Addresses

   Michael Douglass
   Spherical Cow Group
   226 3rd Street
   Troy, NY  12180
   United States


   Cyrus Daboo
   Apple Inc.
   1 Infinite Loop
   Cupertino, CA  95014
   United States