Re: [ietf-privacy] [Tzdist] [saag] Fwd: WGLC for draft-ietf-tzdist-service-05

Paul Eggert <eggert@cs.ucla.edu> Sat, 31 January 2015 08:15 UTC

Return-Path: <eggert@cs.ucla.edu>
X-Original-To: ietf-privacy@ietfa.amsl.com
Delivered-To: ietf-privacy@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E5B1A1B28; Sat, 31 Jan 2015 00:15:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4w0hcZ9I2iaP; Sat, 31 Jan 2015 00:15:20 -0800 (PST)
Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by ietfa.amsl.com (Postfix) with ESMTP id 74BFA1A882D; Sat, 31 Jan 2015 00:15:20 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 9C3BEA60089; Sat, 31 Jan 2015 00:15:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu
Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Bjp3yOkSmGR; Sat, 31 Jan 2015 00:15:19 -0800 (PST)
Received: from [192.168.1.9] (pool-173-55-11-52.lsanca.fios.verizon.net [173.55.11.52]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 3B2E5A60085; Sat, 31 Jan 2015 00:15:19 -0800 (PST)
Message-ID: <54CC8F13.6060808@cs.ucla.edu>
Date: Sat, 31 Jan 2015 00:15:15 -0800
From: Paul Eggert <eggert@cs.ucla.edu>
Organization: UCLA Computer Science Department
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Lester Caine <lester@lsces.co.uk>, saag@ietf.org, ietf-privacy@ietf.org, Eliot Lear <lear@cisco.com>
References: <CADZyTkkLu6qQ9LCqDkTHA9o+-YVvQuaUp33kqkAt=PRaQS-Jew@mail.gmail.com> <CADZyTkkCrvTam_ba7Tq6A-cHAVZn+ktKqwWsr_PNQaz2jyTkUQ@mail.gmail.com> <874mr9aucv.fsf@alice.fifthhorseman.net> <54CBC609.4010309@lsces.co.uk> <87egqcq827.fsf@alice.fifthhorseman.net>
In-Reply-To: <87egqcq827.fsf@alice.fifthhorseman.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf-privacy/pBWMQs2TKWCIh_KzA4gk-hhnOJs>
Cc: Time Zone Data Distribution Service <tzdist@ietf.org>
Subject: Re: [ietf-privacy] [Tzdist] [saag] Fwd: WGLC for draft-ietf-tzdist-service-05
X-BeenThere: ietf-privacy@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Privacy Discussion List <ietf-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-privacy/>
List-Post: <mailto:ietf-privacy@ietf.org>
List-Help: <mailto:ietf-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Jan 2015 08:15:21 -0000

Daniel Kahn Gillmor wrote:
> Given that the all-tzdata-as-a-software-update mechanism is already
> available, I sort of assumed that this draft was intended for systems
> that don't already have such a mechanism.

My impression is that the tzdist protocol is also intended to supplement those 
operating system updates, or in the long run to replace them.  In practice these 
OS updates are sometimes delayed or deferred, and I think the hope is partly 
that such problems would occur less often with tzdist.

Privacy ought to easier for this usage of tzdist, as network observers shouldn't 
be able to learn more about full tzdata updates than they can for any other OS 
update.

> Consider an internet-connected bedside alarm clock

Given your comments, I'd think that any such alarm clock should get the entire 
tz database, just as an OS update would.  This would preserve privacy better 
than having the alarm clock query only about updates to America/Los_Angeles and 
Europe/Paris.