Re: [Ntp] New Version Notification for draft-gruessing-ntp-ntpv5-requirements-03.txt

James <james.ietf@gmail.com> Fri, 15 October 2021 09:27 UTC

Return-Path: <james.ietf@gmail.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7468A3A18D4 for <ntp@ietfa.amsl.com>; Fri, 15 Oct 2021 02:27:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 K_Ti-d0fr6NA for <ntp@ietfa.amsl.com>; Fri, 15 Oct 2021 02:27:24 -0700 (PDT)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 E9A1B3A0EE8 for <ntp@ietf.org>; Fri, 15 Oct 2021 02:27:23 -0700 (PDT)
Received: by mail-ed1-x530.google.com with SMTP id t16so35467399eds.9 for <ntp@ietf.org>; Fri, 15 Oct 2021 02:27:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lrAVzLqhAIpbPfKqZ3UI32PDFKaS3CwePKc1Xu8DJMw=; b=VYn0hScEtcUrxzewl11URA5s3HF4zLn7pnu6pe8WQ/6lxrnaUuUFxQbkOgIq/M7VBl PMvs0KVQX7l07UfVhV2HPyLjlyyn39oaR1nvD/O3TyukYYwXUqLX0pdLPkIk/GcfAzFA Na2xr2K73purgXHQ+OAoftfpqMfcs8fR0heGklP0cjnDPupagfKRojdHrUmLw9fwJee1 l4c1wt0ZyKJumq4A69NT+6qikRBOkeexti01O3df0XWfGQq+FgeefsCwN8cnXT8hrZGz 48YQiH3lwIZhIBo9NCSxmb6GALtqvLmeuS/Tebiam4tYnhlztuBa3MJ6OrLFE9gClDVF WCaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=lrAVzLqhAIpbPfKqZ3UI32PDFKaS3CwePKc1Xu8DJMw=; b=XwmShyMGu0b4YLp0h/gBOFZrK7Fn4rnDjPZBEaxm8TWhuAgLxFnlxpovCSyLkoxvGX V9r1VwQlC1BmyI7yxiY1xg7J7LNSvsMV1EAVIyuxxx79+TiMa+o0iJxHxifNXpKXhtTe 7e+w4miSKpiYIMxZhih6aJ8BNyO2/BzQl/Mewb6bZFH1VHSJMxQ2nuORzNRXihVdVouJ b8kpvNkUjqPmQFIF7XEwCZlQ0+4FeK9x+bvEGHuTK1rSpuXZiq9qLEeYkZ/UID6Dl6ky jvPkzSFSeIBRx849DPGTNI1QPAAvoPlKJJsN+jQcfTmuwUSxPaf1kxxQWmm6DoyesOtQ 41yQ==
X-Gm-Message-State: AOAM531lX9824woB5r/Txl0WNV1s3rjN+HTwMpJx36AbbQYV71aYZ67T HUObyRTFYe/BKF8UevKhM0nDClbOoVACxQ==
X-Google-Smtp-Source: ABdhPJwSSyS/0Akm2fS5051oc1XJITjxuZmJhhh5Eb3mAVs57phXPqRnhpfi3C0MHf7Pbe/H0lLebw==
X-Received: by 2002:a17:906:5cf:: with SMTP id t15mr5318004ejt.375.1634290041399; Fri, 15 Oct 2021 02:27:21 -0700 (PDT)
Received: from smtpclient.apple ([2001:984:65b0:1:9d06:8bc7:9aa8:2605]) by smtp.gmail.com with ESMTPSA id m15sm5560935edd.5.2021.10.15.02.27.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Oct 2021 02:27:20 -0700 (PDT)
From: James <james.ietf@gmail.com>
Message-Id: <E469D9A7-7445-49D9-A8A2-82BA7BF1FA27@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B623CA67-16A8-4517-BB65-E8985EB8CA16"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Fri, 15 Oct 2021 11:27:20 +0200
In-Reply-To: <DB8PR02MB5772AC97BFE2D7C1139EFDC0CFB89@DB8PR02MB5772.eurprd02.prod.outlook.com>
Cc: NTP WG <ntp@ietf.org>
To: Doug Arnold <doug.arnold@meinberg-usa.com>
References: <163386015957.12424.6997038478834885480@ietfa.amsl.com> <CAO+dDx=6baLhf9LwSMvR1F0ieuLO6NXmExYLDvcCF2tgchHs8w@mail.gmail.com> <DB8PR02MB5772AC97BFE2D7C1139EFDC0CFB89@DB8PR02MB5772.eurprd02.prod.outlook.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/s2Xk1CvZLJVacZB6UktErxwvQYY>
Subject: Re: [Ntp] New Version Notification for draft-gruessing-ntp-ntpv5-requirements-03.txt
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Oct 2021 09:27:30 -0000

Doug,
Thanks for the feedback, responses inline.

> On 15 Oct 2021, at 00:45, Doug Arnold <doug.arnold@meinberg-usa.com> wrote:
> 
> Thanks James,
>  
> I think that this is pretty close to what is needed for ntpv5.  I like the separation of protocol and algorithms, and the use of monotonic timescale for timestamp fields (at least by default), and the insistence on security. 
>  
> I have two comments:
> 1. Why do you think that encryption should be the default mode? People often consider timing information to be critical but not secret.  Also it is likely to affect accuracy in implementations by adding a variable delay to encrypt. 

We’ve had a few discussions on list on the subject in the past, and the draft says:

> Encryption and authentication MUST be provided by the protocol specification as a default and MUST be resistant to downgrade attacks...

To put this another way, I think the specification must provide confidentiality as well as authentication, and that if either is applied they cannot be removed from a connection (aka a security downgrade) which makes authentication the minimum and doesn’t necessarily mandate confidentiality.

This section in particular could probably use some editing and clarification to better explain this [1] as we’ll likely need consensus calls made.

> 2. I think that it is better to allow leap smearing and make it a visible part of the protocol than to pretend it is not going to happen.  On this topic I think that Miroslav’s proposal was more realistic.  Data center network architects tell me they definitely plan to continue to do leap smearing.

In other use cases such as publicly accessible NTP, leap smearing has effectively fragmented the pools of services a given host can use as mixing smeared and non-smeared services is not a good idea, in addition to the start/end and cadence of smearing being inconsistent between providers [2]. I think that having a “linear, monotonic timescale” and leap smearing together are contradictory and so having smearing in the wire format would requiring changing that. My proposal doesn’t prevent smearing of a clock being synchronised, it’s about removing the smear from the wire.

- J

1: https://github.com/fiestajetsam/draft-gruessing-ntp-ntpv5-requirements/issues/4
2: https://mailarchive.ietf.org/arch/msg/ntp/hJTpPJ1L5bzBPhLtiQzL3bk75LM/