Re: [Ntp] NTS Pools

"\"Dr. Dieter Sibold\"" <> Thu, 22 February 2024 15:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D0D20C151078 for <>; Thu, 22 Feb 2024 07:44:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Status: No, score=-2.105 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZAGAb3DhhSqD for <>; Thu, 22 Feb 2024 07:44:19 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id F3AF8C14F6E9 for <>; Thu, 22 Feb 2024 07:43:49 -0800 (PST)
Received: by with SMTP id 4fb4d7f45d1cf-563c0f13cabso10339826a12.3 for <>; Thu, 22 Feb 2024 07:43:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1708616628; x=1709221428;; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=wcIJvFKrKlKgqCFQBw0YxaX2f7bfXFGM4aGEqLUGfwI=; b=FRtU2jAfI00P/FG9CWkYhMaNQFle+5sY3pf7uk9cSh89ffiLca/f4PEYl0ZcVEaykj JPUwJ5Nt3EQFxzf2UHjD8TGMqgNVOGUtSCsrEOj/9Hka4wDVWTAFhOrhfbKDhczBDdAM OfeG3bUbE6tfmih3sbnONy9QkfaG1Mdv+yv8LMZcqLaUzNMquhgza5dq3xHQ34CcJ/Oc 828gHaGf1tt//TgZgeWbch6IexdCNR2yCPJx/nKIcAzlAalnAlVk5AOvFpPvc5RZvxJw SRri06LjKPOiKCdaE3+cnks53QyfepId2Br49oZtF/pvOijdHU2aSVu1widRBYGblzUE 9/Ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1708616628; x=1709221428; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wcIJvFKrKlKgqCFQBw0YxaX2f7bfXFGM4aGEqLUGfwI=; b=N1MxzsaQTw3eaIH3CTBcJC+kgkWfFnjSqI+s1G+DMCPwBbyFu0OVAOfjdY2xGT4Mol s+lSC7KR5sMUEw5ZTLjqwFBsSJ9qm6qTePeTo/FPt8+sj2hQD7vnGt6KjUQc/ifaNSHG z1r4wih/XDu3T9Mzlks4AzOjYwbNNRxeNjbXF4I6uhKKJAEE1ng3WWdPqW/0YuADZXgI FRiCkLySUqlmQzbJ+WhfDKnhrNlZG9nY7tS3gascgUZzCFcGQ0NPgTgU4qGpagF2zdNW HjF1X1WPKPyX80zeBEZV2ln2Fg3RsTN5+IBOuePEIfErbHRLuar9wfYCx55YoR6BLAZz Zokg==
X-Forwarded-Encrypted: i=1; AJvYcCUMfYmzQafFSIfEdCzuS9K3v+f3GQacnROYddi9ACgGJxWCAkTgldB8WLcSxAdN7qq5DFSGypAb6NBw1Dg=
X-Gm-Message-State: AOJu0YyDIKuLdlPeh1i00bViqWdGQcl+KGdjYktnTMLpF8fnEfVDs+3c sLTy0LU7eYMntGTAka2uEYlCPEIg5WRlL+YfaDD7cJ3H37uJP163
X-Google-Smtp-Source: AGHT+IGIz6xWR4Dq8gSKqbjH2FjIZKLaiwGIE+65CMKWD97EUqvv4+4EcemM3M+yfDA/643GRksPsg==
X-Received: by 2002:aa7:d4d0:0:b0:564:66b2:2075 with SMTP id t16-20020aa7d4d0000000b0056466b22075mr8944796edr.10.1708616627549; Thu, 22 Feb 2024 07:43:47 -0800 (PST)
Received: from [] ( [2003:c0:3f06:f900:5ccd:fa60:54ec:96b3]) by with ESMTPSA id eo11-20020a056402530b00b00564acce7d31sm2994265edb.45.2024. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Feb 2024 07:43:46 -0800 (PST)
From: "\"Dr. Dieter Sibold\"" <>
Cc: David Venhoek <>, NTP WG <>,,, Rainer Bermbach <>
Date: Thu, 22 Feb 2024 16:43:46 +0100
X-Mailer: MailMate (1.14r6016)
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Ntp] NTS Pools
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Feb 2024 15:44:22 -0000

Hi Martin,

thanks for your thought an NTS protected NTP pools.

Please find comments below.

On 22 Feb 2024, at 15:39, wrote:

> Hi David,
> I was talking with Krisof Teichel, Dieter Sibold and Rainer Bermbach about how we should handle NTS secured NTP pools. It's not easy as there are different perspectives on the purpose, use cases and security considerations. In general, I think I can provide support from the PTB side, even though I have very little time for it at the moment. (...NTS4PTP is very time consuming)
> I also spent a lot of time thinking about this and discussed the possibilities intensively with Rainer Bermbach. The main results are described in my recently published dissertation [, Chapter 4.2]. I would like to give you a brief overview here. First of all: NTS4PTP already solves this problem for PTP and provides an NTS subprotocol that can also be used for NTP (more details below).
> My personal goal
> -----------------------------------
> From my point of view, I would like to see the communication between the NTS-KE server and the NTS capable NTP server defined. Especially in large local networks, a central NTS-KE server could be set up which, similar to the NTP pool, assigns the known NTP servers to the requesting clients. This way an admin can connect any number of NTP servers to the NTS-KE server without having to reconfigure any NTP client.
> However, I would NOT want to change public NTP pools, as this is not absolutely necessary to provide NTS-secured NTP. Depending on the implementation approach, there are different advantages/disadvantages and challenges (see below).
> Use Case and Security Considerations
> --------------------------------------------------------------------
> The biggest question is who wants to use NTS-secured NTP pools and what security promises should be fulfilled. If someone wants "secure time or secure time synchronization", then NTS-secured NTP pools do not provide it. Although NTS secures the communication between the NTP client and NTP server, it does not provide any indication as to whether the time server itself is trustworthy. So it makes a difference whether I intentionally add 1, 2 or 3 NTS-capable time servers in the NTP configuration, or whether I hand over control and let some be assigned to me at random. should at least always keep this in mind.
From my point of view we carefully should differentiate between secured time synchronisation and trustworthy time sources. So my claim would be: Usage of NTS for NTP pools would indeed increase security of time exchanges. However, the question of trust in the member of the NTP pools remains unsolved. I don’t think that this can be solved by enhancing NTS. I would suppose that the question of trust is to be solved independently from NTS. In many respects that’s similar to HTTPS, where you need TLS to secure exchange of information and a PKI to establish trust in the Web server.

> NTS pool solution approach 1: The simplest variant: nothing.
> ---------------------------------------------------------------------------
> You could simply provide the NTP pools with NTS-capable NTP servers. When a client receives different IP addresses for NTP servers, it can simply check via TCP port 4460 if an NTS-KE server is present. If so, it will perform the key establishment protocol for the corresponding NTP server. This is also more secure, since no central NTS-KE server is involved in the key negotiation. ...NTP pools could possibly be modified to signal which NTP servers are capable of NTS, or a client could explicitly ask for NTS capable NTP servers. The only disadvantage is that the client has to perform several TLS handshakes... but this should be acceptable.
> NTS pool solution approach 2: central NTS-KE server
> --------------------------------------------------------------------
> This method gives the NTS-KE server the ability to assign NTP servers and also to implement other services such as load control. NTS for NTP already provides mechanisms for port and IP negotiation. However, there are a number of challenges to be addressed.
> 1: Time server registration
> ------------------------------------------------------
> The communication between the NTS-KE server and the NTP server has to be defined. Since the NTS-KE protocol does not include message type detection, another NTS subprotocol is required. I have done this in NTS4PTP, which can also be easily extended for NTP.
> 2: Authorization
> ---------------------------------
> In short, the question of who can register with a central NTS-KE server and who issues the certificates. If this is not a question, then of course anyone can provide an NTS-secured NTP server. ...this goes back to the question of trust in the time server.
> 3. cookie format
> ---------------------------------
> If the NTS-KE server generates cookies, the cookie format has to be defined. The cookie format described in RFC8915 is currently recommended. Deviations are therefore allowed. Although all known NTS implementations follow this format, they all differ in field length and byte order and are therefore not compatible!
> 4. nonce collisions / key recovery
> ---------------------------------------------------
> If the NTS-KE server and the NTP server are separated, it must be ensured that both sides do not accidentally use the same key with the same nonce, otherwise a key recovery is possible. Either the nonce generation has to be regulated or we need 2 master keys.
> 5. miscellaneous
> --------------------------------------------
> Then there are many more questions:
> - Keeping the TLS channel open for multiple requests (you solved this with the keep-alive record; I solved it without a record based on timeouts and 'close_notify')
> - Heartbeat messages for NTP servers
> - Registration revocation mechanisms for NTP servers
> - possibly data synchronization between NTS-KE servers (for resilience)
> - ...
> just my thoughts
> have a nice day.
> kind regards,
> Martin
> PS: there is an error in my thesis (chapter 4.2.5): we have no Source PortIdentity in NTP ignore it ;)
> __________________________________________
> Dr.-Ing. Martin Langer
> Physikalisch-Technische Bundesanstalt (PTB)
> Working Group 4.42 "Dissemination of Time"
> Bundesallee 100,
> 38116 Braunschweig (Germany)
> Tel.: +49 531 592-4470
> E-Mail:
> __________________________________________

> _______________________________________________
> ntp mailing list