[Ntp] Shorter NTS packets?

Miroslav Lichvar <mlichvar@redhat.com> Thu, 09 December 2021 09:52 UTC

Return-Path: <mlichvar@redhat.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C84903A08C8 for <ntp@ietfa.amsl.com>; Thu, 9 Dec 2021 01:52:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 (1024-bit key) header.d=redhat.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id q6_kNh_3Wyz0 for <ntp@ietfa.amsl.com>; Thu, 9 Dec 2021 01:52:51 -0800 (PST)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com []) (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 367403A08C5 for <ntp@ietf.org>; Thu, 9 Dec 2021 01:52:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1639043569; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=zEzgFJl5h9ZxBHxKA2TcL62rNMvYSgyDsIlXN8g1zVw=; b=heHdZpUw0YmWNPoEz2DV7Kk/nABgXA103oe+iqy0P8VIfKRIl1Smrwn11vVqGVnRT1uBI+ uPTVt6YYBqz+6yUg+wM7wTeVpe7vooKzPT4bpAY8Ux02ojhRlwWId0t1Fq/ZR0GHUUp2uW 7m2VtLXldreja5RPwBKLfpW+z5NlWkg=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com []) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-227-qLu-52WqOcWCeLCt-kbV7g-1; Thu, 09 Dec 2021 04:52:46 -0500
X-MC-Unique: qLu-52WqOcWCeLCt-kbV7g-1
Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9AF71612D8 for <ntp@ietf.org>; Thu, 9 Dec 2021 09:52:45 +0000 (UTC)
Received: from localhost (unknown []) by smtp.corp.redhat.com (Postfix) with ESMTPS id 216D219729 for <ntp@ietf.org>; Thu, 9 Dec 2021 09:52:44 +0000 (UTC)
Date: Thu, 09 Dec 2021 10:52:43 +0100
From: Miroslav Lichvar <mlichvar@redhat.com>
To: ntp@ietf.org
Message-ID: <YbHR69xnXYUR3NY3@localhost>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.84 on
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="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/YGGNfm27ApFOysXoMd_qApnREKs>
Subject: [Ntp] Shorter NTS packets?
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: Thu, 09 Dec 2021 09:52:54 -0000

>From the discussion about the alternative port it looks like we might
be stuck with the UDP port 123 forever.

There is one relatively simple thing we could potentially do to make
NTS more reliable without horribly wasting bandwidth. We could make
the Uniq ID extension field optional in some common cases. That would
save 36 octets and make the typical NTPv4+NTS packet short enough to
not be impacted by the length-specific filtering that was described in
this post:


The Uniq ID field was added to NTS to avoid any assumptions about
NTP's susceptibility to replay attacks. However, if we specify some
requirements for NTP, the Uniq ID could be unnecessary. Support
for this feature could be negotiated over NTS-KE to avoid
incompatibilities with existing server implementations following
RFC 8915, which requires the Uniq ID to be always present.

The NTP header has the transmit timestamp field (64 bits). It can be
fully randomized (as was proposed in the data minimization draft). The
validity of the server NTS key encrypting cookies can be limited (e.g.
to 1 week) and also the rate of NTP requests can be limited (e.g. to 1
per second). Clients that need to send requests at a higher rate are
likely synchronizing over local network, where the filtering is not
happening, and they could still use the Uniq ID field as before.

Together these limits limit the number of packets authenticated by a
C2S/S2C key. With the 1 week / 1s example that's 604800 packets. If
I'm calculating right that's about 1 in 100 million chance of a
collision per key.

If that is not good enough, the transmit timestamp could be used as a
counter, possibly encrypted to not break the privacy-protecting
property of NTS. This would require the client to be careful with how
it saves the NTS keys and cookies to not reuse a transmit timestamp
after restart, etc.

Does this make sense?

Miroslav Lichvar