Opened 8 years ago

Closed 8 years ago

#7 closed defect (fixed)

security consideration: why do we need an insecure version of the timezone service?

Reported by: lear@… Owned by: cyrus@…
Priority: major Milestone:
Component: service Version:
Severity: Active WG Document Keywords:
Cc:

Description

In draft-douglass-timezone-service there is the following text:

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.

If every enterprise and his mother is going to be running one of these
things, then it makes sense to consider a plain text version of the
service. However, if it's going to be the big calendar providers that
are distributing, then it seems to me that this is not a substantial
barrier to deployment.

Change History (2)

comment:1 Changed 8 years ago by lear@…

  • Component set to service
  • Severity changed from Candidate WG Document to Active WG Document

Proposal from Eliot made

<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

_
Tzdist mailing list
Tzdist@…
https://www.ietf.org/mailman/listinfo/tzdist

comment:2 Changed 8 years ago by mglt.ietf@…

  • Resolution set to fixed
  • Status changed from new to closed

Hi Lester, tzdist@…,

--On September 22, 2014 at 3:26:03 PM -0400 Cyrus Daboo <cyrus@…> wrote:

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.

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.

Note: See TracTickets for help on using tickets.