Re: [Ntp] NTPv5: big picture

Miroslav Lichvar <mlichvar@redhat.com> Tue, 05 January 2021 09:08 UTC

Return-Path: <mlichvar@redhat.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 B1B213A00D2 for <ntp@ietfa.amsl.com>; Tue, 5 Jan 2021 01:08:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.359
X-Spam-Level:
X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.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 CXVrzaXRy1hi for <ntp@ietfa.amsl.com>; Tue, 5 Jan 2021 01:08:08 -0800 (PST)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1639D3A00E9 for <ntp@ietf.org>; Tue, 5 Jan 2021 01:07:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1609837679; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HvAg9a9QGzzACDM1Kn00wtytle9LpETDmm8cS4ANVlY=; b=bFLoUDNgk/NYfx5VbE7ZkJ3ZdR0MIuG9wl4E+IVlbwCfO04HBny3gwGocA8+voC+5GKoFh +eiLAKujymr20j3poaA8N9MwjI+vfbCG2mC00Z3ekpxI7ewU1T0RnsXaKmfPccLIKfEcOX dApnFg4fucms7hO/61DXSpZxGP/QyMs=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-62-fns9-kgxP-eSZpSwmmV1VQ-1; Tue, 05 Jan 2021 04:07:57 -0500
X-MC-Unique: fns9-kgxP-eSZpSwmmV1VQ-1
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 478631005504; Tue, 5 Jan 2021 09:07:56 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3F8011349A; Tue, 5 Jan 2021 09:07:55 +0000 (UTC)
Date: Tue, 05 Jan 2021 10:07:53 +0100
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Dieter Sibold <dsibold.ietf@gmail.com>
Cc: NTP WG <ntp@ietf.org>, Hal Murray <hmurray@megapathdsl.net>
Message-ID: <20210105090753.GC3008666@localhost>
References: <20210101025440.ECE3340605C@ip-64-139-1-69.sjc.megapath.net> <20210104151813.GB2992437@localhost> <0D36B305-90EE-4FCD-A53E-8941388BBA97@gmail.com>
MIME-Version: 1.0
In-Reply-To: <0D36B305-90EE-4FCD-A53E-8941388BBA97@gmail.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mlichvar@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/1dN5tlveJbzj4C-uHPGXUgbP3BY>
Subject: Re: [Ntp] NTPv5: big picture
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: Tue, 05 Jan 2021 09:08:13 -0000

On Mon, Jan 04, 2021 at 06:31:31PM +0100, Dieter Sibold wrote:
> > With most options I think the client can simply send a request using
> > that option and see if the server's response has it. It can do that
> > with every request, or try it only occasionally to reduce the average
> > length of the request and response.
> > 
> > For more complex or conflicting features, the support can be indicated
> > with a flag in an extension field.
> 
> If security-by-default is enforced the NTS-KE could serve as a robust mean
> to exchange the server’s capabilities.

NTS-KE is supposed to be used only rarely (clients should save
cookies and keys), so I don't think it would be a good mechanism for
discovery of the server's capabilities, even if NTS was required by
NTPv5. They can change due to an upgrade or reconfiguration without
breaking the NTS context (requiring new NTS-KE session).

-- 
Miroslav Lichvar