I'm relatively new to the NTP pool, however doesn't the pool action
itself hedge against the sort of interference that this proposal aims to
protect against? If an individual server is being intercepted or
otherwise tampered with, and made to drift significantly away from true
time, won't it
Hi Hal,
On 2020-03-11 22:30, Hal Murray wrote:
> The RFC is close to getting published.
>
> Do you know about it? Any thoughts about how to get the pool to support it?
>
> In case you and/or others aren't familiar with it, here is a rough
> description. Details here:
>
On Wed, Mar 18, 2020 at 11:20:18AM -0600, Ask Bjørn Hansen wrote:
> On Mar 12, 2020, at 9:54, Miroslav Lichvar <[1]mlich...@redhat.com>
> wrote:
>- clients only trusting a pool certificate authority (that only issues
>short lived certs for [2]x.nts.ntppool.org or some
We are far enough down in the weeds that I have lost the big picture of this
branch of the discussion.
I think we want to encourage servers that already have their own certificate
to join the pool. That means minimal changes to their current NTP/NTS setup.
"None" is the desired amount, but
I think it is mostly "a solution in search of a problem".
When you really (need to) worry that someone in between you and the
network at large is
carefully modifying all time replies in such a way that your local clock
would be considerably
off time without you detecting it (e.g. because it
> On Mar 12, 2020, at 11:36, Miroslav Lichvar wrote:
>
> I think that's no different from how NTP clients currently work with the
> pool. If a server is removed from the pool, the clients will use it until
> it's marked as a falseticker or unreachable. It doesn't matter if it was
> removed
For anyone interested in piggybacking one of the encrypted DNS efforts, there's
a list of example use-cases being developed at:
https://github.com/Encrypted-DNS-Deployment-Initiative/Use-Cases
And the initiative's site and information about participation is at
https://www.encrypted-dns.org/
On Thu, Mar 12, 2020 at 09:24:55AM -0500, Ask Bjørn Hansen wrote:
> On Mar 12, 2020, at 09:45, Miroslav Lichvar wrote:
> >
> > One of my suggestions was to specify a NTS-KE redirect where the
> > server wouldn't provide cookies, but a TTL and a list of hostnames and
> > addresses. It would
> On Mar 12, 2020, at 09:45, Miroslav Lichvar wrote:
> One of my suggestions was to specify a NTS-KE redirect where the
> server wouldn't provide cookies, but a TTL and a list of hostnames and
> addresses. It would basically be DNS over NTS-KE. Easy to implement on
> both servers and clients. If
On Mar 12, 2020, at 09:45, Miroslav Lichvar wrote:
>
> One of my suggestions was to specify a NTS-KE redirect where the
> server wouldn't provide cookies, but a TTL and a list of hostnames and
> addresses. It would basically be DNS over NTS-KE. Easy to implement on
> both servers and clients. If
On Thu, Mar 12, 2020 at 02:23:54AM -0700, Hal Murray wrote:
> If all goes well, the NTS-KE step is very rare. The client gets 8 cookies.
> Each NTP exchange uses a cookie and gets back a new cookie. If an occasional
> packet is lost, the client can ask for extras. The NTP side just keeps
>
On Thu, Mar 12, 2020 at 02:23:54AM -0700, Hal Murray wrote:
> You said "shorter lived certs" a couple of times. Are you thinking of short
> enough to cover temporarily removing servers with bad time from the pool? If
> so, that won't work.
>
> If all goes well, the NTS-KE step is very rare.
> SRV records with server names then used in the KE.
I think that works. Unfortunately, there is no POSIX API for SRV.
It needs DNSSEC or something equivalent.
You said "shorter lived certs" a couple of times. Are you thinking of short
enough to cover temporarily removing servers with bad
On Thu, Mar 12, 2020 at 01:56:47AM -0700, Hal Murray wrote:
> I think the way to use DNSSEC is to setup a local caching resolver that uses
> DNSSEC and edit your local /etc/resolv to point to it rather than whatever
> they are currently using.
Yes, but how will the NTS client know the hostname
mlich...@redhat.com said:
> DNSSEC disadvantages
> - additional complexity for NTS clients
> - not widely supported (i.e. NTS clients would need to have their own
I think the way to use DNSSEC is to setup a local caching resolver that uses
DNSSEC and edit your local /etc/resolv to point to
er...@rail.eu.org said:
> If this needs non trivial work on the server side, then you can say goodbye
> to many servers in the pool...
There was no intention to require NTS. All the old stuff should continue to
work as it currently does.
If you are running ntpsec, it's pretty simple to add
On Thu, Mar 12, 2020 at 08:44:33AM +0100, Miroslav Lichvar wrote:
> There is a different problem that might need to be addressed first.
> MITM attackers could circumvent NTS simply by joining the pool. How
> could that be prevented or minimized? Not accept any new members and
> trust the old ones
Le 11/03/2020 à 22:30, Hal Murray a écrit :
>
> The RFC is close to getting published.
>
> Do you know about it? Any thoughts about how to get the pool to support it?
>
> In case you and/or others aren't familiar with it, here is a rough
> description. Details here:
>
On Thu, Mar 12, 2020 at 12:03:10AM +0100, Kurt Roeckx wrote:
> On Wed, Mar 11, 2020 at 02:30:11PM -0700, Hal Murray wrote:
> >
> > Any thoughts about how to get the pool to support it?
>
> I think that if we want to use NTS with the pool, that we need a
> secure way of getting the list of
On Wed, Mar 11, 2020 at 02:30:11PM -0700, Hal Murray wrote:
>
> Any thoughts about how to get the pool to support it?
I think that if we want to use NTS with the pool, that we need a
secure way of getting the list of servers. That probably means
either DNSSEC or TLS. Both have their advantages
(Again from an address that can email the list...)
> On Mar 11, 2020, at 16:40, Ask Bjørn Hansen wrote:
>
>
> I haven’t carefully weighed the pros and cons, but variations on the
> following is what I have considered. I don’t know that they’d work as the RFC
> has been described. Past
The RFC is close to getting published.
Do you know about it? Any thoughts about how to get the pool to support it?
In case you and/or others aren't familiar with it, here is a rough
description. Details here:
https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/
The idea is
22 matches
Mail list logo
