Re: [Ntp] [internet-drafts@ietf.org: New Version Notification for draft-gruessing-ntp-ntpv5-requirements-02.txt]

Danny Mayer <mayer@pdmconsulting.net> Mon, 14 June 2021 18:25 UTC

Return-Path: <mayer@pdmconsulting.net>
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 03DF53A2D66 for <ntp@ietfa.amsl.com>; Mon, 14 Jun 2021 11:25:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Ue4iBLM1_Y0R for <ntp@ietfa.amsl.com>; Mon, 14 Jun 2021 11:25:36 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35C163A2D62 for <ntp@ietf.org>; Mon, 14 Jun 2021 11:25:29 -0700 (PDT)
Received: from newusers-MBP.fios-router.home (pool-108-26-179-179.bstnma.fios.verizon.net [108.26.179.179]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4G3fyB48jqzMNV7; Mon, 14 Jun 2021 18:25:22 +0000 (UTC)
To: Miroslav Lichvar <mlichvar@redhat.com>, James <james.ietf@gmail.com>
Cc: ntp@ietf.org
References: <20210522183113.7ovb2crqg7h5q6fs@de970ef05f79> <YMc3qU1UHSvQT/Gu@localhost>
From: Danny Mayer <mayer@pdmconsulting.net>
Message-ID: <20be95b2-5d71-7c5f-eda0-2a4de57c6da4@pdmconsulting.net>
Date: Mon, 14 Jun 2021 14:25:21 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <YMc3qU1UHSvQT/Gu@localhost>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/nNoFMYsLQYEV4l6GhBFgOXhM3Fg>
Subject: Re: [Ntp] [internet-drafts@ietf.org: New Version Notification for draft-gruessing-ntp-ntpv5-requirements-02.txt]
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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: Mon, 14 Jun 2021 18:25:40 -0000

I haven't had a chance to read the draft yet, but I wanted to respond 
based on Miroslav's comments.

On 6/14/21 7:04 AM, Miroslav Lichvar wrote:
> On Sat, May 22, 2021 at 06:31:13PM +0000, James wrote:
>> URL:            https://www.ietf.org/archive/id/draft-gruessing-ntp-ntpv5-requirements-02.txt
>> Status:         https://datatracker.ietf.org/doc/draft-gruessing-ntp-ntpv5-requirements/
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-gruessing-ntp-ntpv5-requirements
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-gruessing-ntp-ntpv5-requirements-02
> I'd like to see this draft considered for adoption. We need to agree
> on the NTPv5 requirements before we can discuss the details of the
> actual protocol.
>
> I have few comments on some specific parts of the document:
>
> - "The specification MUST have support for servers to notify clients
>     that the service is unavailable, and clients MUST have clearly
>     defined behaviours honouring this signalling."
>
>    This looks like a good goal but I suspect we may not be able to
>    define a useful behavior for an unauthenticated context.
If this is equivalent to the NTP v4 KOD packets that's okay. I don't 
know what "unavailable" means otherwise.
>
> - "Leap second smearing SHOULD NOT be part of the wire specification"
>
>    I think the protocol needs to have some way to indicate that the
>    server has leap smearing enabled. Servers implementing leap smear,
>    but clients not knowing about it (e.g. using its own leap second
>    source) is a major concern in some environments.
The protocol needs to STRONGLY indicate how they are handling leap 
seconds so that recipients can decide whether or not to use the 
timestamps being returned. There are clients who CANNOT use smeared leap 
seconds so they would need to drop the packet if it is in the smear 
mode. I have a proposal to deal with leap seconds in a more general way 
which I will send out later.
> - "Encryption and authentication MUST be provided by the protocol
>     specification as a default"
>
>    It's not clear to me what the default means here. That it is enabled
>    by default in all implementations that support it?

We should certainly NOT be doing encryption on an NTP packet? What are 
you trying to hide? Timestamps are obsolete almost before you use them 
and there is nothing confidential about them. Authentication IS 
important and should be secured by protocols like NTS or MAC's or (let 
me say it anyway!) Autokey.

Danny