Re: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts

Hal Murray <> Tue, 10 September 2019 09:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C94FE12009E for <>; Tue, 10 Sep 2019 02:36:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.035
X-Spam-Level: *
X-Spam-Status: No, score=1.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GZnAXvvCvCf3 for <>; Tue, 10 Sep 2019 02:36:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 844CD120052 for <>; Tue, 10 Sep 2019 02:36:24 -0700 (PDT)
Received: from shuksan (localhost []) by (Postfix) with ESMTP id BA37A406063; Tue, 10 Sep 2019 02:36:23 -0700 (PDT)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: Miroslav Lichvar <>
From: Hal Murray <>
In-Reply-To: Message from Miroslav Lichvar <> of "Tue, 10 Sep 2019 09:47:04 +0200." <20190910074704.GB21704@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 10 Sep 2019 02:36:23 -0700
Message-Id: <>
Archived-At: <>
Subject: Re: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Sep 2019 09:36:30 -0000 said:
> IIRC, there are few implementations that do that. openntpd is probably the
> most widely used one. As a server, it just checks if the packet is 48 or 64
> octets long and that the mode is 1 or 3. ...

What's the 64 byte case?

I'm trying to make it fit with old style shared key authentication (no 
extension field) but that's 20 or 24 bytes, 4 bytes for the key-ID and 16 or 
20 for MAC.

----------- said:
>> I propose we just avoid this situation entirely by making NTS a
>> mandatory part of v5.
> I don't think that is a good idea. I'm sure we can figure out something
> simple that doesn't require TCP or TLS. For instance, moving the origin field
> in the header would prevent such broken servers from sending a valid
> response. 

I'm looking for a way to ask a server what it supports without knowing what it 
supports.  That would be simple if we had thought about it back when designing 
version 0 of the protocol.

NTS-KE uses ALPN so you get version info as part of the TLS handshake.

But I'd like something light weight.  The complication is that we also have to 
determine if the server supports telling us what it supports.  I don't see how 
to do that in a simple clean way.  No response can mean either it doesn't 
support that packet or the server is down.  You can try something 
simpler/older to see if the server is up, but no response doesn't tell you if 
the server is down or the network is lossy.  We can probably work around that, 
but by that time it's no longer clean and simple.

We should be sure to put something like this into the v5 protocol so it will 
be there when v6 comes along.

These are my opinions.  I hate spam.