Subject: [Ntp] short information

From: Martin Langer <[email-masked]>
Date: Sun, 24 Mar 2019 13:30:06 +0100

my "server nts3-e.ostfalia.de" does not use the OpenSSL workaround anymore. Now the long TLS exporter string is valid

best regards,
Martin

---

From: "Gary E. Miller" <[email-masked]>
Date: Sun, 24 Mar 2019 12:38:19 -0700

Yo All!

On Sun, 24 Mar 2019 13:30:06 +0100
Martin Langer <[email-masked]> wrote:

> my "server nts3-e.ostfalia.de" does not use the OpenSSL workaround
> anymore. Now the long TLS exporter string is valid

Looks like the party is over, but the rellim.com servers running NTPsec
now use the long exporter string as well.

They are connecting fine now to:

    server ntpmon.dcs1.biz nts
    server zoo.weinigel.se:4446 nts
    server nts-test.strangled.net:443 nts
    server nts3-e.ostfalia.de:443 nts noval
    server ntp1.glypnod.com nts

But not:

    server khronos.mikieboy.net nts

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	[email-masked]  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

---

From: Christer Weinigel <[email-masked]>
Date: Mon, 25 Mar 2019 14:11:21 +0100

>      server ntp1.glypnod.com nts

Neat.  To me it's quite impressive to have four separate implementations 
talking to each other.

BTW, if someone wants to try it out, I have set up a NTSKE server on 
zoo.weinigel.se:4447 which includes a NTPv4 Server Negotiation record in 
its response.  The hostname in the response is "mail.weinigel.se", which 
is just an alias for "zoo.weinigel.se".

Since we (netnod) will be using the NSN record it would be nice if all 
known implementations support this record.  Hal implemented support for 
NSN in the NTPSec client yesterday.  If the others have the time, please 
add it to the other clients too.

  /Christer

---

From: Sanjeev Gupta <[email-masked]>
Date: Mon, 25 Mar 2019 22:49:37 +0800

> add it to the other clients too.

I am running NTPsec git head, and when I specify zoo.weinigel.se:4447 ,  I
am able to sync with the NTP server on port 4126.

Thanks,
-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane

---

From: Watson Ladd <[email-masked]>
Date: Mon, 25 Mar 2019 17:35:49 +0100

time.kc2kdm.com is up for nts-ke on port 1234. The udp part is not
implemented yet. Please try it!

On Mon, Mar 25, 2019, 3:50 PM Sanjeev Gupta <[email-masked]> wrote:

> I am running NTPsec git head, and when I specify zoo.weinigel.se:4447 ,
> I am able to sync with the NTP server on port 4126.
>
> Thanks,
> --
> Sanjeev Gupta
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 26 Mar 2019 10:47:55 +0100

On Mon, Mar 25, 2019 at 02:11:21PM +0100, Christer Weinigel wrote:
> zoo.weinigel.se:4447 which includes a NTPv4 Server Negotiation record in its
> response.  The hostname in the response is "mail.weinigel.se", which is just
> an alias for "zoo.weinigel.se".

Is there a good use case for using hostnames instead of IP addresses?
I don't like this dependency of NTS-KE on DNS very much (at least in
my case it's a significant complication in the client implementation).

-- 
Miroslav Lichvar

---

From: Hal Murray <[email-masked]>
Date: Tue, 26 Mar 2019 03:28:13 -0700

[email-masked] said:
> Is there a good use case for using hostnames instead of IP addresses? I don't
> like this dependency of NTS-KE on DNS very much (at least in my case it's a
> significant complication in the client implementation). 

The certificate is normally tied to a FQDN.

If a bad guy intercepts your DNS requests and feeds you bogus answers, he can 
deny you service but not give you bogus time.  (assuming you check the 
certificate)

You could setup your configuration area so it took both IP Address and 
name-in-cert.  I would think of it as caching the DNS lookup.

-- 
These are my opinions.  I hate spam.

---

From: Richard Welty <[email-masked]>
Date: Tue, 26 Mar 2019 11:34:06 +0100

> The certificate is normally tied to a FQDN.

commonly, but it's not a requirement. one can imagine scenarios where an
operator might choose differently.

richard

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 26 Mar 2019 11:43:59 +0100

> The certificate is normally tied to a FQDN.

Yes, but I think that is specific to TLS, not NTP or NTS.

I think the most common case by far will be NTS-KE running on the NTP
server itself. To me it would make sense to not require all clients to
support this extra name resolving, but rather do it on the server if
it needs to be done at all.

-- 
Miroslav Lichvar

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 26 Mar 2019 10:47:26 +0000

NTS-KE uses TLS handshake. If you are using X509 certificates, you have to use a DNS name. If not, you should document either (a) a certificate type; or (b) specific rules for validating the server identity, see RFC 7817.  ipAddresses are allowed in subjectAltNames (as IPAddress, not DNSname)

---

From: Hal Murray <[email-masked]>
Date: Tue, 26 Mar 2019 04:24:13 -0700

> I think the most common case by far will be NTS-KE running on the NTP server
> itself. To me it would make sense to not require all clients to support this
> extra name resolving, but rather do it on the server if it needs to be done
> at all.

The key idea is that you have to check the certificate.  If you can't check 
the certificate, you have no security.  Currently, the only widely deployed 
certificate technology uses FQDNs.

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 26 Mar 2019 12:37:21 +0100

> certificate technology uses FQDNs.

Ok, but you don't need to send any DNS requests in order to verify the
certificate. AFAIK nothing else in NTP and NTS requires resolving
hostnames, except this rarely used NTS-KE record. It looks like an
unnecessary complication to me. The servers that will need it could
simply provide their clients with the IP address directly.

-- 
Miroslav Lichvar

---

From: Daniel Franke <[email-masked]>
Date: Tue, 26 Mar 2019 12:54:00 +0100

I think the ability to send a hostname will become important in the
case where the NTS-KE server is run by a pool administrator while the
NTP server is run by an individual operator. The NTP operator ought to
be able to move to a new IP address by updating its DNS, without
having to coordinate this with the pool administrator. So either the
client needs to be able to perform DNS lookups or the server needs to
be able to do so on the client's behalf, and the former is preferable
because it enables the DNS server to give a geographically-dependent
response, assigning the client to a server physically close to it.

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 26 Mar 2019 13:01:56 +0100

> response, assigning the client to a server physically close to it.

I don't think you want to use a pool in combination with NTS-KE.

Kurt

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 26 Mar 2019 13:10:09 +0100

> I don't think you want to use a pool in combination with NTS-KE.

To clarify, I don't think you want to use a pool with NTS-KE where
not all the servers involved are run by the same organisation. So
it could work for something like NIST that runs multiple servers,
but I don't think it's a good idea to do it for something like
pool.ntp.org.

Kurt

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 26 Mar 2019 13:13:23 +0100

On Tue, Mar 26, 2019 at 12:54:00PM +0100, Daniel Franke wrote:
> having to coordinate this with the pool administrator. 

At least in the case of the largest NTP pool (pool.ntp.org) the pool
admin is constantly monitoring the servers and needs to know their
current addresses, even if it didn't need them for DNS responses.

> So either the

The geo-aware DNS server is run by the pool admin, not the server's
admin.

Also, wouldn't it be more practical to run a separate KE on each NTP
server in the pool? The pool admin would be just dealing with DNS and
certificates. No need to deal with NTS-KE keys, etc.

-- 
Miroslav Lichvar

---

From: Hal Murray <[email-masked]>
Date: Tue, 26 Mar 2019 05:21:20 -0700

> certificate. AFAIK nothing else in NTP and NTS requires resolving hostnames,
> except this rarely used NTS-KE record. It looks like an unnecessary
> complication to me. The servers that will need it could simply provide their
> clients with the IP address directly. 

Ahh...  Several layers to the confusion here.

I (now) think you are talking about using a host name in the Server 
Negotiation record as was the example that started this thread.

I've been talking about using DNS to locate the NTS-KE server.  The name you 
feed to DNS is the name you will use to check the certificate you get back 
from the TLS connection to the NTS-KE server.  If you want to avoid that DNS 
lookup, you can cache the IP Address, perhaps manually by typing it into the 
config file, but the client needs the name that will be in the certificate.

I agree that in the common case, at least for the short term, the NTS-KE 
server will be co-located with the NTP server and there will be no Server 
Negotiation record.  That may change if something like the pool wants to use 
NTS.

Anybody have a guess as to what fraction of NTP clients are using the pool?

---

From: Christer Weinigel <[email-masked]>
Date: Tue, 26 Mar 2019 14:00:14 +0100

> my case it's a significant complication in the client implementation).

Sorry for the late answer, but yes, since a server is not allowed to 
reply with multiple NTPv4 Server Negotiation records, a NTSKE server 
that wants to point to multiple IP addresses for the NTP server, the 
only way to do that is using DNS.

The reason a NTSKE server wants to reply with multiple addresses could 
be because the NTP server speaks both IPv4 and IPv6, or because the NTP 
server really has multiple IP addresses (e.g. load 
balancing/redundancy).  Both cases are true for Netnods NTP server, our 
NTP server speaks both IPv4 and IPv6 and does have multiple interfaces.

   /Christer

---

From: Christer Weinigel <[email-masked]>
Date: Tue, 26 Mar 2019 14:25:55 +0100

> certificates. No need to deal with NTS-KE keys, etc.

Agreed.  In my opinion the main reason to use DNS is to be able to have 
alternate IP addresses for "one" NTP server.  With "one" I mean a 
server, or set of servers that behave as if they are logically one 
server.  They accept the same NTS cookies, and have to respond with 
cookies that are usable by all other NTP servers pointed out by the same 
NTSKE server.

The NTSKE server can return an IPv4 address, an IPv6 address, or a DNS 
hostname.  If a DNS hostname is returned, a client should normally use 
one and only one of the A/AAAA responses, it should not treat the 
addresses as a pool.  If the client fails to reach one of the IP 
addresses it received (because the address is a IPv4/IPv6 address and 
the client lacks IPv4/IPv6 connectivity, or because one of the 
IP-addresses is unreachable for some other reason), it can fall back to 
one of the another addresses.

For those wishing to run a pool, the pool should be a set of NTSKE servers.

As usual, this is all my opinion, and since I'm fairly new to NTS, so I 
might have missed something obvious.

   /Christer

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 26 Mar 2019 15:50:37 +0100

On Tue, Mar 26, 2019 at 02:00:14PM +0100, Christer Weinigel wrote:
> The reason a NTSKE server wants to reply with multiple addresses could be
> because the NTP server speaks both IPv4 and IPv6,

I think it could simply respond with an address in the same family as
the TCP connection was made. Or is there a case where this wouldn't
work?

> or because the NTP server
> really has multiple IP addresses (e.g. load balancing/redundancy). 

Couldn't the NTS-KE server select one address randomly in order to
implement a load balancing?

If the DNS name had multiple addresses and the one that the client is
currently using stops responding, should it try the other addresses
before starting a new NTS-KE exchange? I think that would be another
major complication in the client that I (and probably others) would
rather avoid.

-- 
Miroslav Lichvar

---

From: Christer Weinigel <[email-masked]>
Date: Tue, 26 Mar 2019 16:21:20 +0100

> the TCP connection was made. Or is there a case where this wouldn't

One of the goals of NTS is to provide anonymity and robustness for 
mobile clients.  Nno information in the unencrypted parts of a NTP 
packet should be reused if the client jumps to a different netork.  If a 
client is hopping between IPv6-capable and non-IPv6-capable networks it 
would be nice if it didn't have to redo the NTSKE negotiation every time 
that happens.  For that reason it's nice if the client can get at least 
an IPv4 and an IPv6 address at the same time and use the appropriate one 
later depending on the network it's on.

For Netnod's use case, we currently have an FPGA with four 10Gbit 
interfaces serving NTP traffic where we can do load balancing between 
the interfaces (and failover in the rare case where an interface dies). 
We are planning to implement NTS on the same FPGA platform and would 
like NTS to be able to do the same thing.  One NTSKE-server and one or 
more NTS timestamping FPGA boards which all act as one big server with 
multiple ports and IP addresses for load balancing.

> major complication in the client that I (and probably others) would

The client doesn't have to do that, but it can if it wants to.  Or it 
can do a new DNS lookup if it doesn't want to start over with the NTSKE 
negotiation.  A simple client can choose to just remember one IP address 
and if that one stops responding it can start over from scratch with 
NTSKE and then do the DNS lookup.

With the current languange in the draft, a Windows or *nix client can 
just hand over the contents of the NTPv4 Server Negotiation record to 
getaddrinfo which will parse an IPv4 address, an IPv6 address or look up 
a DNS name and return a list of addrinfo structures.  The client then 
selects the first entry which has an ai_family which is usable for it.

(It's probably a good idea to do some kind of sanity check of the 
contents first, maybe use a regexp which limits the contents to 
[-.:A-Za-z0-9] just to catch strings that can't be valid.)

   /Christer

---

From: Christer Weinigel <[email-masked]>
Date: Tue, 26 Mar 2019 17:15:28 +0100

On 2019-03-26 16:21, Christer Weinigel wrote:
> mobile clients.  

My general impression is that a lot of the complexity in NTS is there to 
give roaming clients anonymity and to add robustness in the face of an 
attacker who is trying to mess with you.

Returning 8 different cookies, that can be refreshed for each NTP 
packet, is a in my opinion a bit of overkill for something as simple as 
NTP.  Except for the use case where you have a mobile client which wants 
to be anonymous as it is hopping between networks, and want to be able 
to do this in the face of an adversary that tries to overload the 
infrastructure so that only a few NTS/UDP packets are getting through 
and setting up a new TLS connection to perform NTSKE is next to impossible.

Someone who doesn't care that much about anonymity doesn't have to 
request 8 cookies with each NTP request, can even decide to reuse 
cookies if a NTP packet is lost, and can choose to remember only one IP 
address for the NTP server and start all over if a NTP request fails.

A client that wants to be more robust and cares about anonymity can make 
sure that it never reuses a cookie, asks for more cookies so that it has 
  8 cookies on hand, and will remember all IP possible addresses for the 
NTP servers so that it randomly can switch between them to hide even 
better and to have a better to find someone to talk to if the network is 
under attack.

Personally I don't particularly care about anonymity and would prefer 
clients to reuse cookies if a packet is dropped.  This would allow us to 
limit the number of cookies and would make an FPGA implementation of NTS 
_much_ simpler.

If we want to ignore those requirements there's a lot of other 
complexity that could be dropped from NTS.  :-)

  /Christer

---

From: "Gary E. Miller" <[email-masked]>
Date: Tue, 26 Mar 2019 11:44:19 -0700

Yo Hal!

On Tue, 26 Mar 2019 04:24:13 -0700
Hal Murray <[email-masked]> wrote:

> > I think the most common case by far will be NTS-KE running on the
> > NTP server itself. To me it would make sense to not require all
> > clients to support this extra name resolving, but rather do it on
> > the server if it needs to be done at all.  
> 
> The key idea is that you have to check the certificate.  If you can't
> check the certificate, you have no security.  Currently, the only
> widely deployed certificate technology uses FQDNs.

Not always, there is always certificate pinning.  You can pin to
the certificate, to the next cert up the chain, or to the root cert.

RGDS
GARY

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 27 Mar 2019 09:47:05 +0100

On Tue, Mar 26, 2019 at 04:21:20PM +0100, Christer Weinigel wrote:
> One of the goals of NTS is to provide anonymity and robustness for mobile
> clients.  Nno information in the unencrypted parts of a NTP packet should be
> reused if the client jumps to a different netork.  If a client is hopping
> between IPv6-capable and non-IPv6-capable networks it would be nice if it
> didn't have to redo the NTSKE negotiation every time that happens.  For that
> reason it's nice if the client can get at least an IPv4 and an IPv6 address
> at the same time and use the appropriate one later depending on the network
> it's on.

That's a good point. I think the right way to do this is to respond
with multiple records instead of relying on DNS. I support your
suggestions from Feb 4th.

-- 
Miroslav Lichvar

---

From: Watson Ladd <[email-masked]>
Date: Wed, 27 Mar 2019 10:05:08 +0100

> the certificate, to the next cert up the chain, or to the root cert.

Root cert pinning is what we have today. It's still important to make
sure bad.com does not imitate good.com even though both have the same
certs from CosmicCA. Also the certificate is not checked on the UDP
part, but the TLS part which is where the client gets the record which
informs it where to go next, so FQDNs are not needed for security at
that step.

DNS resolution is the way most NTP services want you to find their
servers, but sadly some devices hardcode IPs. If these devices also
pin certificates this could be problematic if the service is not
expecting it.

---

From: "Dieter Sibold" <[email-masked]>
Date: Wed, 27 Mar 2019 10:27:45 +0100

In our NTP infrastructure we are using DNS names only. We gave up with 
ip addresses. We also recommend our customers to use DNS names. In the 
past we had a lot of issues with using IP address.

- Dieter

Dieter Sibold
[email-masked]

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 28 Mar 2019 15:01:57 +0100

On Wed, Mar 27, 2019 at 10:27:45AM +0100, Dieter Sibold wrote:
> In our NTP infrastructure we are using DNS names only. We gave up with ip
> addresses. We also recommend our customers to use DNS names. In the past we
> had a lot of issues with using IP address.

This subthread is just about the NTS-KE server negotiation record.

An NTP implementation which supports running NTS-KE on a separate
address than NTS-NTP (e.g. what Netnod is implementing) will most
likely be configured with interface names or IP addresses. Even if it
was configured with hostnames, it could resolve them to IP addresses
and return them in the server negotiation record.

A nice side effect of this approach is that it will save DNS traffic.

-- 
Miroslav Lichvar