Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist)

From: S Moonesamy <[email-masked]>
Date: Thu, 03 Jul 2014 14:32:07 -0700

At 08:06 20-06-2014, Barry Leiba wrote:
>Cyrus Daboo has proposed a new working group in the Applications Area,
>and I'm initiating charter discussion on it:
>
>https://datatracker.ietf.org/doc/charter-ietf-tzdist/
>
>We'll have the charter discussion here on apps-discuss.  Assuming a
>working group comes out of this, we'll create a new mailing list for
>the actual work, once the charter is done.

I took a quick look at the proposed charter.

   "The following are Out of scope for the working group:

   - Any changes to the IANA timezone database process or infrastructure,
     as documented in RFC 6557, other than recommendations for possible
     security enhancements."

A few months ago there was a hearing in the United States.  A member 
of the legislature asked the ICANN President a question (I do not 
recall the exact words):

   What is the ccTLD for Crimea?

http://www.bbc.com/news/world-europe-28144334

The TZ database itself is not an IETF Contribution.  Any enhancements 
is up to the TZ Coordinator.  I suggest that the IETF does not make 
any recommendations about the TZ database.  I think that it is better 
for the IETF to stay away from that process.

According to BCP 175:

   'TZ Database:  The Time Zone Database, sometimes referred to as the
      "Olson Database".  This database consists of information about
       offsets from UTC for different localities, including daylight
       saving time (DST) transition information.'

There isn't any mention of a "IANA timezone database" in that 
BCP.  Would the IESG like to include the TZ Database in discussions 
about the IANA Transition?

   'The working group can consider adding a mechanism, such as a
    "namespace" prefix, to differentiate different timezone sources,
    but the nature of the timezone identifiers used will be
    controlled by the sources themselves.'

Formalizing time zone sources may lead down a path where the question 
of the authoritative source is raised.  "namespace" could create the 
conditions for contentious strings [1].

Regards,
S. Moonesamy

1. I haven't given much thought to all this.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 4 Jul 2014 09:14:15 -0400

Hi, SM.
I don't see much in your message that's actionable.  For the bits that are:

> The TZ database itself is not an IETF Contribution.  Any enhancements is up
> to the TZ Coordinator.  I suggest that the IETF does not make any
> recommendations about the TZ database.  I think that it is better for the
> IETF to stay away from that process.

The only thing that the charter leaves in scope with regard to that
happens if we find security issues, while building the distribution
protocol.  I think it's a good idea to leave that in scope (and I
don't expect it to be triggered).  The IESG will consider your comment
in this regard.

> There isn't any mention of a "IANA timezone database" in that BCP.

Indeed; I changed "IANA Time Zone Database" and "IANA timezone
database" to "Time Zone Database" in version -03.  Thanks.

Barry

On Thu, Jul 3, 2014 at 5:32 PM, S Moonesamy <[email-masked]> wrote:
> A few months ago there was a hearing in the United States.  A member of the
> legislature asked the ICANN President a question (I do not recall the exact
> words):
>
> The TZ database itself is not an IETF Contribution.  Any enhancements is up
> to the TZ Coordinator.  I suggest that the IETF does not make any
> recommendations about the TZ database.  I think that it is better for the
> IETF to stay away from that process.
>
> According to BCP 175:
>
> There isn't any mention of a "IANA timezone database" in that BCP.  Would
> the IESG like to include the TZ Database in discussions about the IANA
> Transition?
>
> Formalizing time zone sources may lead down a path where the question of the
> authoritative source is raised.  "namespace" could create the conditions for
> contentious strings [1].
>
> Regards,
> S. Moonesamy
>

---

From: Barry Leiba <[email-masked]>
Date: Sun, 6 Jul 2014 10:51:02 -0400

> database" to "Time Zone Database" in version -03.  Thanks.

Further, in response to comments from the <tz> list, I've changed all
instances of "timezone" in the charter to "time zone" (in -04).  I've
asked the Secretariat to change it in the working group name: I can't
change that bit.

I'm happy to see that the spelling of "time zone" was the only flaw in
the proposed charter.

Barry

---

From: Pete Resnick <[email-masked]>
Date: Mon, 7 Jul 2014 00:36:33 +0300

On 7/4/14 4:14 PM, Barry Leiba wrote:
> protocol.

Perhaps Cyrus could better explain, but: What sort of "security issues", 
and security issues with *what*, was this referring to? I'm mildly 
inclined to remove that line from the charter, but I'd like to hear what 
was being considered.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 07 Jul 2014 12:34:03 -0400

Hi Pete,

> inclined to remove that line from the charter, but I'd like to hear what

During apps-discuss discussion, it was suggested that we might want to 
digitally sign the time zone data, rather than just rely on transport layer 
security (TLS) to validate the data service server. If we opt for such a 
thing, we may want to have the Olson data signed in a more reliable manner 
than at present. RFC 6557 did indicate that IANA would be in charge of 
maintaining the private key used to sign the data, but I think right now 
the available signature is created using the TZ co-ordinator's own private 
key.

-- 
Cyrus Daboo

---

From: S Moonesamy <[email-masked]>
Date: Mon, 07 Jul 2014 21:15:25 -0700

Hi Cyrus,
At 09:34 07-07-2014, Cyrus Daboo wrote:
>During apps-discuss discussion, it was suggested that we might want 
>to digitally sign the time zone data, rather than just rely on 
>transport layer security (TLS) to validate the data service server. 
>If we opt for such a thing, we may want to have the Olson data 
>signed in a more reliable manner than at present. RFC 6557 did 
>indicate that IANA would be in charge of maintaining the private key 
>used to sign the data, but I think right now the available signature 
>is created using the TZ co-ordinator's own private key.

The above has never been mentioned on the TZ mailing list.  I suggest 
discussing about that on the TZ mailing list if it is considered as a 
security issue.

Regards,
S. Moonesamy

---

From: Pete Resnick <[email-masked]>
Date: Tue, 8 Jul 2014 03:11:57 +0300

On 7/7/14 7:34 PM, Cyrus Daboo wrote:
> digitally sign the time zone data, rather than just rely on transport 
> layer security (TLS) to validate the data service server. If we opt 
> for such a thing, we may want to have the Olson data signed in a more 
> reliable manner than at present. RFC 6557 did indicate that IANA would 
> be in charge of maintaining the private key used to sign the data, but 
> I think right now the available signature is created using the TZ 
> co-ordinator's own private key.

Aha. Then might I suggest an edit so that we're a bit more specific and 
it does not appear (as SM interpreted) that we're possibly going to step 
on toes. (The following was written on a very long plane flight. 
Wordsmithing may be necessary.)

OLD
    - The time zone data distribution protocol will use current security
    protocols to protect the integrity and confidentiality of what is
    distributed.  Even public time zone data can represent a significant
    privacy exposure when it is associated with the user or endpoint that
    is retrieving it.

    The following are Out of scope for the working group:

    - Any changes to the Time Zone Database process or infrastructure,
    as documented in RFC 6557, other than recommendations for possible
    security enhancements.

NEW
    - The time zone data distribution protocol will use current security
    protocols to protect the integrity and confidentiality of what is
    distributed, including the ability to communicate that the data
    received from its original source, such as the Time Zone Database,
    has maintained integrity. Even public time zone data can represent a
    significant privacy exposure when it is associated with the user or
    endpoint that is retrieving it.

    The following are Out of scope for the working group:

    - Any changes to the Time Zone Database process or infrastructure,
    as documented in RFC 6557. However, the WG may work with IANA
    in order to make integrity checking information, like public keys,
    readily accessible for protocol use.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 8 Jul 2014 09:55:41 -0400

>    endpoint that is retrieving it.

I don't strongly object to the change, but I don't see the benefit of
it.  The sentence starts by saying that it will protect integrity, and
you're adding "the ability to communicate" that integrity happened.
While we might or might not want to have that, it seems an odd thing
to call out at the charter level, rather than leaving it for the
protocol.

>    readily accessible for protocol use.

This looks fine to me (modulo changing "like" to "such as", which I
will do).  Isn't this part sufficient to address your concern, Pete?

Barry

---

From: Pete Resnick <[email-masked]>
Date: Tue, 8 Jul 2014 09:04:30 -0500

> to call out at the charter level, rather than leaving it for the

So the point I was *trying* to make (brain damage notwithstanding) was 
that TLS provides integrity, but not the kind that Cyrus was talking 
about here. TLS provides integrity of the data between the tz dist 
server and client, but not between the original data (i.e., the Time 
Zone Database) and the client. And since we're mentioning something 
about it below, I thought it was worth explicitly calling out. But if 
you think it's covered in the original, I'm OK with that.

> will do).  Isn't this part sufficient to address your concern, Pete?

Yep.

pr

---

From: Barry Leiba <[email-masked]>
Date: Tue, 8 Jul 2014 10:09:56 -0400

> So the point I was *trying* to make (brain damage notwithstanding) was that
> TLS provides integrity, but not the kind that Cyrus was talking about here.
> TLS provides integrity of the data between the tz dist server and client,
> but not between the original data (i.e., the Time Zone Database) and the
> client. And since we're mentioning something about it below, I thought it
> was worth explicitly calling out.

Ah, yes.  I missed that wrinkle.  Then maybe this will make us both understand?:

OLD NEW

NEW NEW
   - The time zone data distribution protocol will use current security
   protocols to protect the integrity and confidentiality of the data as
   it is distributed, and may also address these issues with respect
   to retrieval of data from its original source (such as the Time Zone
   Database). Even public time zone data can represent a
   significant privacy exposure when it is associated with the user or
   endpoint that is retrieving it.

END

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 08 Jul 2014 10:17:37 -0400

Hi Pete,

--On July 8, 2014 at 9:04:30 AM -0500 Pete Resnick 
<[email-masked]> wrote:

> about here. TLS provides integrity of the data between the tz dist server
> and client, but not between the original data (i.e., the Time Zone
> Database) and the client. And since we're mentioning something about it
> below, I thought it was worth explicitly calling out. But if you think
> it's covered in the original, I'm OK with that.

So the tricky thing here - which we should delve into more in any WG - is 
that the Time Zone Database data has to be "processed" to extract the kind 
of information that zoneinfo files and iCalendar VTIMEZONE objects 
represent. That is done using the zic tool (for zoneinfo - provided in the 
"binary" TZ database package) and 3rd party tools for iCalendar. Given 
that, the current PGP signature on the TZ database data package file cannot 
be used to directly indicate the validity of the "processed" data being 
distributed by the TZ data distribution service.

I think Barry's latest proposed text covers what we need to say right now.

-- 
Cyrus Daboo

---

From: Pete Resnick <[email-masked]>
Date: Tue, 8 Jul 2014 09:17:55 -0500

>     endpoint that is retrieving it.

Opinions of security ADs would be helpful to confirm that we captured it 
right, but that's cool with me.

pr

---

From: Barry Leiba <[email-masked]>
Date: Tue, 8 Jul 2014 10:27:27 -0400

> right, but that's cool with me.

Both changes made in -05.  The Sec ADs have not posted their positions
yet, so we'll see what they have to say when they do.

b

---

From: Eliot Lear <[email-masked]>
Date: Tue, 08 Jul 2014 17:32:34 +0200

Hi everyone,

> will do).  Isn't this part sufficient to address your concern, Pete?

As mentioned earlier in this thread, RFC 6557 *already* asks the IANA to
take responsibility for signing the database (as mentioned earlier in
this thread).  Before the WG takes on any changes here, we should find
out what, if any, bottleneck exists, and what the views and experiences
of the TZ Coordinator & IANA are.

Eliot

---

From: "Resnick, Pete" <[email-masked]>
Date: Tue, 8 Jul 2014 15:50:25 +0000

Eliot,

The edit we just made to the charter text makes it absolutely clear that the WG shall make *no changes*; taking on changes is specifically out of scope. The only thing they are chartered to do in this regard is to consult with IANA in order to figure out how to get the signed data if it's not obvious. Do you think that is not clear?

pr

--
Sent from my Droid. Pardon my brevity.

Eliot Lear <[email-masked]> wrote:

Hi everyone,

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 08 Jul 2014 17:59:36 +0200

On 7/8/14, 5:50 PM, Resnick, Pete wrote:
> Eliot,
>
> The edit we just made to the charter text makes it absolutely clear
> that the WG shall make *no changes*; taking on changes is specifically
> out of scope. The only thing they are chartered to do in this regard
> is to consult with IANA in order to figure out how to get the signed
> data if it's not obvious. Do you think that is not clear?

What I'm saying is that there is no point in even that much if you don't
have some facts on the ground about why it hasn't happened already.

Eliot