Subject: [Tzdist] proposal to resolve issue 7: why do we need an insecure version of the timezone service

From: Eliot Lear <[email-masked]>
Date: Fri, 19 Sep 2014 10:19:11 +0200

<chair hat off>

No argument has been made that this service would be run where the
inconvenience of using TLS would become a concern.  Therefore, I propose
the following changes:

Top of Section 4.1

OLD:

4.1.  Server Protocol

   The time zone data distribution service protocol uses HTTP [RFC7230]
   for query and delivery of data.

NEW:

4.1.  Server Protocol

   The time zone data distribution service protocol uses HTTP over TLS
[RFC7230], [RFC5246]
   for query and delivery of data.

Bottom of Section 4.1, OLD:

   Most security considerations are already handled adequately by HTTP.
   However, given the nature of the data being transferred and the
   requirement it be correct, all interactions between client and server
   SHOULD use an HTTP connection protected with TLS [RFC5246] as defined
   in [RFC2818].

NEW:

<nothing>

Section 4.2.1.1

OLD:

   This specification adds two service types for use with SRV records:

   timezone:  Identifies a Time Zone Data Distribution server that uses
      HTTP without transport layer security ([RFC2818]).

   timezones:  Identifies a Time Zone Data Distribution server that uses
      HTTP with transport layer security ([RFC2818]).

NEW:

   This specification a new service type for use with SRV records:

   timezone:  Identifies a Time Zone Data Distribution server that uses
      HTTP with transport layer security ([RFC2818]).

And later in that same section:

OLD:

   Example: service record for server without transport layer security.

   _timezone._tcp SRV 0 1 80 tz.example.com.

   Example: service record for server with transport layer security.

   _timezones._tcp SRV 0 1 443 tz.example.com.

NEW:

   Example: service record for a server;

   _timezone._tcp SRV 0 1 443 tz.example.com.

In Section 4.2.1.2:

OLD:

   Example: text record for service with transport layer security.

   _timezones._tcp TXT path=/timezones

NEW:

   Example: text record for service:

   _timezone._tcp TXT path=/timezones

In Section 9:

Validation is part of the TLS specification and need not be mentioned...

OLD:

>    Clients and servers making use of a time zone
>    data distribution service SHOULD use HTTP over TLS and verify the
>    authenticity of the service being used before accepting and using any
>    time zone data from that source.

NEW:

<none>

And also this:

OLD:

   Clients that support transport layer security as defined by [RFC2818]
   SHOULD try the "_timezones" service first before trying the
   "_timezone" service.  Clients MUST follow the certificate
   verification process specified in [RFC6125].

NEW:

<none>

I would ask Cyrus to consider changes in examples in Section 6(if any). 
A quick review of the use of a Host: header is in order in those examples.

Also, Section 10.4.2 should be dropped, and the description in 10.4.1
modified accordingly.

Eliot

---

From: Lester Caine <[email-masked]>
Date: Fri, 19 Sep 2014 10:12:49 +0100

> inconvenience of using TLS would become a concern.  Therefore, I propose

Sorry - but forcing this is not the job of tzdist.
While TLS is probably the preference for a central distribution system
it should not be forced on every user. Users implementing a private
system should not be forced to have to use it? I doubt that they would
even bother with the restriction but tagging that as not compliant does
not make sense?

-- 
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: Eliot Lear <[email-masked]>
Date: Fri, 19 Sep 2014 12:02:25 +0200

Hi Lester,

> even bother with the restriction but tagging that as not compliant does

Tthe IETF has made clear in RFC 7258 that we have to take into account
and address pervasive surveillance issues.  The WG may decide to *not*
require use TLS, but it should have good reason to do so.  You are
welcome to make an argument not to require TLS, but both the shepherd
for the draft and the IESG must be persuaded.  In the issue, I asked the
very question you asked: is it likely that enterprises would implement
such a system on their own?  Allow me to proffer my own answer:

1.  No.  While the draft makes provision for discovery in a given
domain, more than likely the service will be made available to consumer
devices and updated through the provider of the operating system or
application.  In such circumstances the cost of using TLS is minute
versus the risk of potential downgrade attack.
2.  If anyone other than the OS or application provider implements this
service, the burden of getting a certificate is still minimal, and
unlikely to reduce deployment of the service.  But I could be convinced
I'm wrong by those who plan to deploy.

Eliot

---

From: Tim Parenti <[email-masked]>
Date: Fri, 19 Sep 2014 14:15:20 -0400

On 19 September 2014 06:02, Eliot Lear <[email-masked]> wrote:

> service, the burden of getting a certificate is still minimal, and unlikely
> to reduce deployment of the service.  But I could be convinced I'm wrong by
> those who plan to deploy.

Not sure if there's an established precedent for handling this, but perhaps
we should require TLS of all public-facing providers as Eliot suggested in
http://www.ietf.org/mail-archive/web/tzdist/current/msg00493.html, but add
somewhere that internal implementations which do not interface with the
public MAY opt not to use it... for some value of the word "public".

--
Tim Parenti

---

From: Steve Allen <[email-masked]>
Date: Fri, 19 Sep 2014 11:37:04 -0700

The end of section 2 is already a paragraph pointing out that tzdist
protocol cannot guarantee anything about the trustworthiness of the
contributors, publishers, nor providers.

The requirement of TLS could be mistakenly interpreted as giving trust
to the entire process, not merely to the final journey between
provider and client.  If TLS is required then rather than deleting
everything about authenticity in Section 9 "Security..."  it might be
better to replace the "should use HTTP over TLS" paragraph with at
least a sentence reiterating the end paragraph of section 2.

--
Steve Allen                 <[email-masked]>                WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165    Lat  +36.99855
1156 High Street            Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

---

From: Daniel Migault <[email-masked]>
Date: Fri, 19 Sep 2014 22:06:16 +0200

To me time zone seems like public data, a bit like the DNS root zone. The
primary concern seems that this data may be authenticated. Currently, the
tzdist data format is out of scope of the charter, but it seems to me that
it would be appropriated to define an authenticated format. In that case
HTTP without TLS could be used to distribute authenticated data.

Currently this authenticated format does not exist, and TLS does not
authenticate the data, but the origin. In fact TLS is not used for
authentication but for privacy protection.
I cannot evaluate how privacy may be affected by retrieving time zone
information, but I am not convinced there is enough concern to make it
mandatory for all systems.
Similarly,  I do not see any reason not to protect privacy. Then, as
authenticated data have not been defined yet, origin authentication is
still better then no authentication at all.

As a result, I would personally make TLS optional if we have the intention
of defining an authenticated time zone format. Otherwise I am fine making
it mandatory as long as it works with IoT.

On Fri, Sep 19, 2014 at 8:37 PM, Steve Allen <[email-masked]> wrote:

> _______________________________________________
> Tzdist mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist
>

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

---

From: Tobias Conradi <[email-masked]>
Date: Fri, 19 Sep 2014 22:24:09 +0200

On Fri, Sep 19, 2014 at 10:06 PM, Daniel Migault <[email-masked]> wrote:
>
> Currently, the
> tzdist data format is out of scope of the charter,

If no format is defined, then it is something like a pure byte
transfer protocol?

And shouldn't it be "a tzdist data format" is out of scope, instead of
"the tzdist data format" is out of scope.

If there would be something like "the tzdist data format" it would be
defined by tzdist, but if it is out of scope it cannot be defined by
tzdist.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Sanjeev Gupta <[email-masked]>
Date: Sat, 20 Sep 2014 14:47:15 +0800

On Fri, Sep 19, 2014 at 6:02 PM, Eliot Lear <[email-masked]> wrote:

> Tthe IETF has made clear in RFC 7258 that we have to take into account and
> address pervasive surveillance issues.

Sec 2 of the RFC says:

Those developing IETF specifications need to be able to describe how
   they have considered PM, and, if the attack is relevant to the work
   to be published, be able to justify related design decisions.  This
   does not mean a new "pervasive monitoring considerations" section is
   needed in IETF documentation.  It means that, if asked, there needs
   to be a good answer to the question "Is pervasive monitoring relevant
   to this work and if so, how has it been considered?"

So,

   1. Is pervasive monitoring relevant to this work?
   2. If yes, what have we decided to do about it?

The current draft's use of TLS seems more on guaranteeing security of the
reply (hence the need to check certificate verification chains).  The TLS
issue does not seem to address privacy issues (if all we want is privacy of
what TZ a client is interested in, we should allow self-signed certs).

There MAY be reasons (none of which are likely to be persuasive in the
general sense), why someone wishes to run a TZDist server with timezone,
rather than timezones.  Maybe it is internal.  Maybe a development team.
This is a decision for the operator, and its users.  We should not forbid
such an operation, any more than insist that the new protocol MUST support
IPv6 (for example).

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane

---

From: Lester Caine <[email-masked]>
Date: Sat, 20 Sep 2014 10:49:04 +0100

On 20/09/14 07:47, Sanjeev Gupta wrote:
> 
> On Fri, Sep 19, 2014 at 6:02 PM, Eliot Lear <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Tthe IETF has made clear in RFC 7258 that we have to take into
>     account and address pervasive surveillance issues.  
> 
> 
> Sec 2 of the RFC says:
> 
> The current draft's use of TLS seems more on guaranteeing security of
> the reply (hence the need to check certificate verification chains). 
> The TLS issue does not seem to address privacy issues (if all we want is
> privacy of what TZ a client is interested in, we should allow
> self-signed certs).
> 
> rather than timezones.  Maybe it is internal.  Maybe a development
> team.  This is a decision for the operator, and its users.  We should
> not forbid such an operation, any more than insist that the new protocol
> MUST support IPv6 (for example).

That sums it up nicely Sanjeev ...
I've just been reading RFC7258, and my very first thought was 'Google
Analytics' ... I always argue strongly about adding this to any site I
support, and prefer my own tools which do not expose personal data to
third parties. It seems to me that making monitoring of traffic more
difficult is somewhat pointless when you then open the barn door anyway?

That the IETF actually have no idea what they are trying to protect
against is quite obvious? But building 'security measures' into a simple
data transfer protocol to 'mitigate PM attacks' seems totally overboard
when supporting a simple internet clock that just wants the next DST
change?

---

From: Daniel Migault <[email-masked]>
Date: Mon, 22 Sep 2014 09:36:52 +0200

Hi,

It seems quite important that we reach a consensus on this issue, so feel
free to comment on it.

BR,
Daniel

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

---

From: Sanjeev Gupta <[email-masked]>
Date: Mon, 22 Sep 2014 15:54:18 +0800

Let the operators, and then the users, decide how much trust they place on
the service.

I agree that IF TLS is used, certs MUST be checked.  If there is no TLS,
however, there is no expectation of security, and that is a call for the
users and operators to make.

Again, I see this as a Security issue, not a Privacy issue.  We suggest
that SMTPs is better than SMTP, and HTTPS is better than HTTP, etc, but
there are cases where we need, or wish, to use HTTP.  Do not make them
non-compliant, please.

---

From: Lester Caine <[email-masked]>
Date: Mon, 22 Sep 2014 09:14:29 +0100

> there are cases where we need, or wish, to use HTTP.  Do not make them

If privacy is so important one might ask 'Why use content that is human
readable at all?' It is a transport layer problem not that of the base
protocol?

---

From: Paul Eggert <[email-masked]>
Date: Mon, 22 Sep 2014 10:16:45 -0700

It's so easy to infer a good approximation of the time zone from IP 
address that encrypting tzdist won't buy most clients much security.  
There are surely applications where HTTPS should be used, but it does 
not seem necessary to require it everywhere.

The energy cost of encrypting and authenticating data is nontrivial for 
small data sizes.  I've seen estimates of overheads from 10% to 70%, 
depending on the implementation; see an example citation below.  So 
there is an argument for not using HTTPS unless it's significantly helpful.

Almenares F. Overhead of using secure wireless communications in mobile 
computing. IEEE T Consum Electr 2013 May;59(2):335-42. 
http://dx.doi.org/10.1109/TCE.2013.6531115

---

From: Tobias Conradi <[email-masked]>
Date: Mon, 22 Sep 2014 19:32:24 +0200

On Mon, Sep 22, 2014 at 7:16 PM, Paul Eggert <[email-masked]> wrote:
> It's so easy to infer a good approximation of the time zone
which time zone?

> from IP address
which IP address?

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Lester Caine <[email-masked]>
Date: Mon, 22 Sep 2014 19:47:06 +0100

>> It's so easy to infer a good approximation of the time zone

Any time zone from any IP address ...

But I have to disagree with that statement since in Europe at least I
can get a central European location for UK clients and visa versa. I've
had to give up using that to identify either location or timezone and
simply rely on UTC until a client actually logs in and the real
timezone_identifier can be established for the PHP server.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 22 Sep 2014 20:57:09 +0200

Chair hat on.

Ok, summing up what I think I've heard:

The working group has discussed the matter of whether or TLS should be
mandatory.  The consensus view was that it is not appropriate to mandate
TLS because the nature of the information is not so revealing as
compared to other information already available, and that there is the
potential increase in power consumption in mobile devices.  As such,
there is cost and no benefit.  Do I have that right?  It's important
because we *will* be asked.

Eliot

---

From: Lester Caine <[email-masked]>
Date: Mon, 22 Sep 2014 20:07:19 +0100

> because we *will* be asked.

In a word YES
But I would amend 'mobile' to simply 'battery powered' ...

---

From: Tobias Conradi <[email-masked]>
Date: Mon, 22 Sep 2014 21:21:48 +0200

> because we *will* be asked.

I don't think that is correct. "not so revealing" refers to privacy?
If yes, then I don't think there is evidence that there is no privacy
issue.

But I don't see why privacy protection should be mandatory.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 22 Sep 2014 15:26:03 -0400

Hi Lester,

> But I would amend 'mobile' to simply 'battery powered' ...

My opinion is that a tzdist server MUST support use of TLS and MAY support 
a mode of operation without TLS. i.e., if a "battery powered" device (or 
anything more sophisticated) wants to use TLS then there should be a 
guarantee that the server does support it.

So the key thing here is to distinguish:

1) "mandatory to implement" - the server needs to make sure a fully 
functional TLS implementation is enabled and ready to use by any clients 
that want to

from:

2) "mandatory to use" - the server requires all clients to use TLS

I think we have consensus that #1 is not what we want. I believe we do need 
to state #2.

-- 
Cyrus Daboo

---

From: Daniel Migault <[email-masked]>
Date: Mon, 22 Sep 2014 21:26:19 +0200

I would also add that TLS does not authenticate the data.

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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 22 Sep 2014 21:34:08 +0200

On 9/22/14, 9:26 PM, Cyrus Daboo wrote:
>
> My opinion is that a tzdist server MUST support use of TLS and MAY
> support a mode of operation without TLS. i.e., if a "battery powered"
> device (or anything more sophisticated) wants to use TLS then there
> should be a guarantee that the server does support it.
>
> functional TLS implementation is enabled and ready to use by any
> clients that want to
>
> from:
>
> I think we have consensus that #1 is not what we want. I believe we do
> need to state #2.

If we are going to go this route, and I think it's a good route to go,
then we should probably state that devices should not negotiate between
TLS and clear text.  This addresses any potential downgrade attack.

Eliot

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 22 Sep 2014 15:40:09 -0400

Hi Eliot,

> TLS and clear text.  This addresses any potential downgrade attack.

Yes that makes sense. It would be nice if there was already a spec that 
described that scenario for HTTP so we could refer to it rather than come 
up with our own. Maybe that is something that the UTA WG could work on, or 
perhaps <http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-03> is already 
sufficient.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 22 Sep 2014 15:42:42 -0400

Hi Lester, [email-masked],

> I think we have consensus that #1 is not what we want. I believe we do

Sorry I got my ones and twos mixed up :-)

What I meant was that #2 ("mandatory to use") is NOT what we want, but #1 
("mandatory to implement") IS what we want.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Mon, 22 Sep 2014 20:55:00 +0100

> I think we have consensus that #1 is not what we want. I believe we do

Sorry that does not read correctly for me.

Client should NOT have to use TLS - battery powered central heating
controllers simply HTTP the data for example.
But a simple server does not also NEED to support TLS if all it is
intending to service is those dumb devices.

As an expanded example here. I'm just quoting for a control system for a
500 apartment building which we would look to service with a local
server to the remove the load off-site. There is no need to load this up
with TLS ...

---

From: Eliot Lear <[email-masked]>
Date: Mon, 22 Sep 2014 21:57:28 +0200

Hi Tobias,

> But I don't see why privacy protection should be mandatory.

Ok.

Eliot