Subject: [secdir] secdir review of draft-ietf-tzdist-service-09

From: Joseph Salowey <[email-masked]>
Date: Wed, 1 Jul 2015 22:19:33 -0700

First, I apologize for the late review. It appears that you may have
already had a secdir review from the revision notes, but I could not find
the review in my archive.

In general it seems the document is in good shape and understandable. I
think the document is ready with nits.  Here are a few minor issues:

1) it might be useful to add something about what is in scope and out of
scope for this document.  What I have in mind is to state the assumption
that the TZ data has been securely transmitted from the contributors to the
publishers to the root provider with its integrity intact and that the
servers are expected to maintain the integrity of the data.

2) It might be useful to qualify the 3rd paragraph as applicable when
discovery is done through DNS SRV records.

Cheers,

Joe

---

From: Eliot Lear <[email-masked]>
Date: Thu, 02 Jul 2015 07:57:18 +0200

Hi Joe,

On 7/2/15 7:19 AM, Joseph Salowey wrote:
> already had a secdir review from the revision notes, but I could not
> find the review in my archive.

The document did already receive a review several months ago, but thank
you anyway for your comments.
>
> In general it seems the document is in good shape and understandable.
> I think the document is ready with nits.  Here are a few minor issues:
>
> 1) it might be useful to add something about what is in scope and out
> of scope for this document.  What I have in mind is to state the
> assumption that the TZ data has been securely transmitted from the
> contributors to the publishers to the root provider with its integrity
> intact and that the servers are expected to maintain the integrity of
> the data.

I think what you are asking for is clearly stated in the converse
already in the Introduction as follows:

>    This specification defines a time zone data distribution service
>    protocol that allows for fast, reliable and accurate delivery of time
>    zone data and leap second information to client systems. 

> discovery is done through DNS SRV records.

Perhaps you can provide some small amount of text as to what you are
suggesting, keeping in mind that it's rather late in the day for this
document.

Regards,

Eliot

---

From: Joseph Salowey <[email-masked]>
Date: Sun, 5 Jul 2015 12:08:54 -0700

On Wed, Jul 1, 2015 at 10:57 PM, Eliot Lear <[email-masked]> wrote:

> I think what you are asking for is clearly stated in the converse already
> in the Introduction as follows:
>
> [Joe]  I'm OK with this.

> suggesting, keeping in mind that it's rather late in the day for this
[Joe] Sure, how about:

 "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. When performing
DNS SRV based discovery in the absence of a secure DNS option, clients
SHOULD check that the..."