Re: [TICTOC] Mirja Kühlewind's Discuss on draft-ietf-tictoc-multi-path-synchronization-05: (with DISCUSS and COMMENT)

Stewart Bryant <stewart.bryant@gmail.com> Mon, 26 September 2016 14:34 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A201A12B2B0; Mon, 26 Sep 2016 07:34:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 jV7BodQK5kVn; Mon, 26 Sep 2016 07:34:45 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D9912B2AA; Mon, 26 Sep 2016 07:34:45 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id l132so155715029wmf.0; Mon, 26 Sep 2016 07:34:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=FRo9gY1nolZsH1YySL2L5JsjsKqCZ5TGkI6vBAgR3CQ=; b=MtI23IqKnz1hsSHEeJZHXhDro7/J6HT/in6HaZ+xt0mHPK6VmF3U72aE4iUWjej8pW ahMF0J0ljhIYRhLsEmJs5wnzP+zZ7tPcOWXnkMxRf5EIEl6snO63MCGF4qwwSiQfXvbu LdEcUrxINnP6B1SlaoOPlHmmvv8SWVOiSmHF0zg/8TZLzTbzChEDb+4ulVtPUGZt7qOn UrA9UmiAr3F/VeOdfdC717DJSa+h9aHm7YKcYAJjchPs9qicCaJQ5qd8vDxqrxSVOomb /OXk5TiStW82aaGHsrAiF5DFd/8zOegFUXb1hKlk0Tnkiwn2cM2Bz5z3NSAeR88OlN56 7RoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=FRo9gY1nolZsH1YySL2L5JsjsKqCZ5TGkI6vBAgR3CQ=; b=dauh1dKvyTfI7R3o+vdt7EMfcVig3g2iSBMa8E8ve6awj5qr0CmkWySAl77zHKjETJ /FctgQBmkn9iopglPoOqQCNqPE9yZKQ2hoP7VIsF7dRWNl6SOhF/W5BV8hZ+/B1gYyKi aFTOfQ2Nkv9K2iSjgAZSPWH1P07PUUsgYafWepJs1yeqT/iJoGezN+E1ZhEdeYl/Vxiu rYsC9raFtINdIh/jzkXtDsUuC+LEvd5/4o+jFFW6xO5nkdd5+ja0BoR3ZoqxrpxEAISw YArpny7o+j4AA000nA6+0e9WNsiJTVBmDYGiLI7K+b/RJReWp1VfDQ38N2t+R3OpYLIp lJyg==
X-Gm-Message-State: AE9vXwOAIrfprvpv30nckX8fs+hZG3wv73XSzrydn3tOfVU8w8oZ8VOyHkZEHtNHXXJIoA==
X-Received: by 10.194.19.164 with SMTP id g4mr18473960wje.110.1474900483805; Mon, 26 Sep 2016 07:34:43 -0700 (PDT)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id bc5sm22694714wjb.37.2016.09.26.07.34.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Sep 2016 07:34:42 -0700 (PDT)
To: Mirja Kuehlewind <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>
References: <147454516251.22463.16980267674502590256.idtracker@ietfa.amsl.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <22a9ade5-a265-ce7f-47cb-eb8c9383bc09@gmail.com>
Date: Mon, 26 Sep 2016 15:34:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <147454516251.22463.16980267674502590256.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tictoc/WFzOVYvWhfNiiEZn1K1cNkdIl1Y>
Cc: draft-ietf-tictoc-multi-path-synchronization@ietf.org, tictoc@ietf.org, odonoghue@isoc.org, tictoc-chairs@ietf.org
Subject: Re: [TICTOC] Mirja Kühlewind's Discuss on draft-ietf-tictoc-multi-path-synchronization-05: (with DISCUSS and COMMENT)
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tictoc/>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2016 14:34:53 -0000


On 22/09/2016 12:52, Mirja Kuehlewind wrote:
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> "Each NTP clock has a set of N IP addresses. The assumption is that
>        the server information, including its multiple IP addresses is
>        known to the NTP clients."
>
> A protocol specification should not make this assumption but describe a
> mechanism how a client gets to know about these IP addresses.

The base NTP protocol gets the time server addresses by configuration, 
and thus
the assumption seems reasonable.

There is something of a chicken and egg problem here since the IP
address of the time servers needs to be securely known, but to run a 
security
protocol needs knowledge of the time. This observation may well point to a
security issue with the popular use of anycast domain names in NTP
configuration since it is difficult to see how you authenticate DNS without
prior access to time to validate a certificate from the DNS server.

You might encourage the IETF to look at this conundrum, and indeed the IOT
folks would like a solution, but I don't think you can burden this draft 
with
solving the problem.

Regards

Stewart