I'll post a rebuttal sometime later this week. As for IETF processes,
though, you're years late. The WG already had a consensus call in 2016
on what NTS-KE's framing format should look like, and it was
unanimous. You can still comment during IETF Last Call and try to
convince the IESG to block the
Hal Murray :
>
> e...@thyrsus.com said:
> >> Do you have an example of where we need to change a
> >> driver variable on the fly?
>
> > No, I'm bothered because I'm (a) not sure we'll never need to do it, and (b)
> > pretty sure what the Dread God Finagle will arrange if I assume we won't.
> > :
e...@thyrsus.com said:
>> Do you have an example of where we need to change a
>> driver variable on the fly?
> No, I'm bothered because I'm (a) not sure we'll never need to do it, and (b)
> pretty sure what the Dread God Finagle will arrange if I assume we won't. :-)
I just looked at the code.
This is why my design sketch for NTPv5 is a JSON profile, and wgy I
intend to file an objection to the KE protocol in the NTS draft.
http://esr.ibiblio.org/?p=8254
--
http://www.catb.org/~esr/";>Eric S. Raymond
I cannot undertake to lay my finger on that article of the
Constituti
Hal Murray :
> Do you have an example of where we need to change a driver variable on the
> fly?
No, I'm bothered because I'm (a) not sure we'll never need to do it, and (b)
pretty sure what the Dread God Finagle will arrange if I assume we won't. :-)
> >> We need to be able to run gpsmon while
e...@thyrsus.com said:
> The two most obvious pain points here are the fudgetime variables. Some
> refclocks set their own custom clock variables, as well; the generic driver
> in particular, I think one other as well.
The fudgetime variables can remain in ntpd.
If the problem is the driver se
dfoxfra...@gmail.com said:
> If you try to measure the cost of the authentication code using log messages
> you're going to get total noise, because the cost of logging a message is
> higher than the cost of doing the authentication. Each invocation of AES-SIV
> should take, in round numbers, 250
Yo Hal!
Whoops, sorry, this was a reply to the other thread...
>
> On Mon, 04 Mar 2019 19:31:07 -0800
> Hal Murray via devel wrote:
>
> > dfoxfra...@gmail.com said:
> > > One thing to keep in mind is that if the client is using
> > > SO_TIMESTAMP but the server isn't, or vice versa, you're go
Yo Hal!
On Mon, 04 Mar 2019 19:31:07 -0800
Hal Murray via devel wrote:
> dfoxfra...@gmail.com said:
> > One thing to keep in mind is that if the client is using
> > SO_TIMESTAMP but the server isn't, or vice versa, you're going to
> > introduce a persistent inaccuracy on the order of a microseco
dfoxfra...@gmail.com said:
> One thing to keep in mind is that if the client is using SO_TIMESTAMP but the
> server isn't, or vice versa, you're going to introduce a persistent
> inaccuracy on the order of a microsecond, due to the resulting asymmetry in
> the point at which the timestamp is capt
Yo James!
On Mon, 4 Mar 2019 15:38:00 -0800
James Browning via devel wrote:
> On Mon, Mar 4, 2019, 1:48 PM Gary E. Miller via devel
> wrote:
>
> > Yo Matthew!
> >
> > On Mon, 4 Mar 2019 21:35:14 +
> > Matthew Selsky wrote:
> >
> > > On Mon, Mar 04, 2019 at 12:11:07PM -0800, Gary E. Mill
On Mon, Mar 4, 2019, 1:48 PM Gary E. Miller via devel
wrote:
> Yo Matthew!
>
> On Mon, 4 Mar 2019 21:35:14 +
> Matthew Selsky wrote:
>
> > On Mon, Mar 04, 2019 at 12:11:07PM -0800, Gary E. Miller via devel
> > wrote:
> >
> > > Given the Comodo mess of last week I expect a lot more people wil
Yo Matthew!
On Mon, 4 Mar 2019 21:35:14 +
Matthew Selsky wrote:
> On Mon, Mar 04, 2019 at 12:11:07PM -0800, Gary E. Miller via devel
> wrote:
>
> > Given the Comodo mess of last week I expect a lot more people will
> > want to do pinning next month.
>
> Do you have a reference for this m
Yo Daniel!
On Mon, 4 Mar 2019 16:32:33 -0500
Daniel Franke wrote:
> On Mon, Mar 4, 2019 at 4:28 PM Gary E. Miller via devel
> wrote:
> > The name in ntp.conf MUST match the name in the cert. Unless you
> > override it ("noval", pin, etc.).
> >
> > > The normal getaddrinfo and friends automa
On Mon, Mar 04, 2019 at 12:11:07PM -0800, Gary E. Miller via devel wrote:
> Given the Comodo mess of last week I expect a lot more people will want to
> do pinning next month.
Do you have a reference for this mess?
Thanks,
-Matt
___
devel mailing list
On Mon, Mar 4, 2019 at 4:28 PM Gary E. Miller via devel
wrote:
> The name in ntp.conf MUST match the name in the cert. Unless you
> override it ("noval", pin, etc.).
>
> > The normal getaddrinfo and friends automatically follow CNAMEs.
> > Thus my comment about needing some DNS code.
>
> Which o
Yo Hal!
On Mon, 04 Mar 2019 12:58:14 -0800
Hal Murray via devel wrote:
> rlaa...@wiktel.com said:
> > CNAMEs don't really help. Certificate validation uses the original
> > name anyway.
>
> I was assuming we could intercept the CNAME and use that for
> certificate validation. Maybe I should
The intended design for running NTS with pool servers is that only the
pool operator runs an NTS-KE server. The NTS-KE server then picks an
NTS-enabled NTP server out of the pool and serves you an appropriate
NTPv4 Server Negotiation Record. Individual server operators, on a
one-time basis, establi
rlaa...@wiktel.com said:
> CNAMEs don't really help. Certificate validation uses the original name
> anyway.
I was assuming we could intercept the CNAME and use that for certificate
validation. Maybe I should have said SRV or TXT or ???
The normal getaddrinfo and friends automatically follow
Yo Hal!
On Mon, 04 Mar 2019 12:46:27 -0800
Hal Murray via devel wrote:
> Gary said:
> >> I would assume that critical infrastructure would be run in a less
> >> insecure environment.
> > Bad assumption. Just look at any data center. There is no way to
> > secure customer machines. Unless yo
Gary said:
>> I would assume that critical infrastructure would be run in a less
>> insecure environment.
> Bad assumption. Just look at any data center. There is no way to secure
> customer machines. Unless you get rid of the customers.
Right. But why would you run your NTS-KE server on a
Yo Hal!
On Mon, 04 Mar 2019 01:58:23 -0800
Hal Murray via devel wrote:
> Gary said:
> >> Otherwise, either do full validation or don't bother with NTS
> >> at all. Pinning counts as full validation.
>
> > I'd be happy if we had per host pinning instead of "noval".
>
> How is per-host pinn
Yo Hal!
On Mon, 04 Mar 2019 02:11:04 -0800
Hal Murray via devel wrote:
> Gary said:
> > Think data center. The data center controls the LAN, but the
> > customers control what is in the containers. Or the hacker that
> > used the latest Wordpress bug to take over the contrainer. And
> > break
Hal Murray via devel writes:
>>> There is no security in the pool anyway, so let's put that discussion
>>> aside for a while.
>> I'd take exception with that statement. If the pool was upgraded to use NTS
>> one way or the other, it _would_ provide some extra security over the status
>> quo. It's
Kurt Roeckx via devel writes:
> There currently isn't a protocol defined between the NTP server
> and the NTS-KE. This would mean that if you want to use it with
> the pool that such a protocol would need to be defined.
A more practical solution until that's been hashed out is to require an
NTS ma
On 3/4/19 3:46 AM, Hal Murray via devel wrote:
> Plan A is to give all the servers the certificate and private key for
> time.nist.gov and do the load sharing via traditional DNS rotation. The
> disadvantage with that is that there are many copies of the private key out
> there. One leak and t
On Mon, Mar 4, 2019 at 9:25 AM Eric S. Raymond wrote:
> The NTP packet-stamp code dates from the before time, when sampling lag
> due to timeslice granularity was an order of magnitude or more worse
> than it is now. From some of its details I'd guess it was written about
> '87 or '88.
I just ch
Yes, if you go back that far then there's been significant change.
Nonetheless, that change isn't relevant. The current granularity of
1ms is still coarse enough that it would be obvious if it were a
factor. Multicore processors are the reason it isn't.
On Mon, Mar 4, 2019 at 9:25 AM Eric S. Raymo
Daniel Franke :
> Scheduler timeslices haven't changed much. The current default on
> Linux is 1ms and it's been that way for a long time. What's changed is
> that everybody has multicore processors now, so contention almost
> never happens.
Your historical baseline isn't long enough. The NTP cod
Hal Murray :
>
> Eric said:
> >> I don't understand. All I was trying to say is that splitting
> >> out the refclock drivers to another process shouldn't make
> >> any difference that is easily visible.
>
> > Maybe. The devil is in the details.
> > I expect some issues around Mode 6. We'd still
One thing to keep in mind is that if the client is using SO_TIMESTAMP
but the server isn't, or vice versa, you're going to introduce a
persistent inaccuracy on the order of a microsecond, due to the
resulting asymmetry in the point at which the timestamp is captured.
On Mon, Mar 4, 2019 at 8:36 AM
On Sun, Mar 3, 2019 at 9:44 PM Eric S. Raymond wrote:
> (Also, it turns out not to be important at post-Y2K machine speeds to
> get those arrival timestamps from the UDP layer ASAP, rather than
> looking at packet read time in userspace. The cost of the latter,
> naive approach is
If you try to measure the cost of the authentication code using log
messages you're going to get total noise, because the cost of logging
a message is higher than the cost of doing the authentication. Each
invocation of AES-SIV should take, in round numbers, 250 CPU cycles,
and processing a typical
Hal Murray :
> I think I'll take a break from NTS and go add a log file for this sort of
> thing. I want a place for the time spent in auth code.
Good idea.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://ice
e...@thyrsus.com said:
>> You need it to verify that you don't need it.
> Interesting point. How do you account for the fact that nobody noticed when
> it was accidentally disabled for six months, though? Definitely the kind of
> thing I'd expect either you or Gary to pick up on, if it made an
Eric said:
>> I don't understand. All I was trying to say is that splitting
>> out the refclock drivers to another process shouldn't make
>> any difference that is easily visible.
> Maybe. The devil is in the details.
> I expect some issues around Mode 6. We'd still need to exchange control
>
Hal Murray via devel :
> Eric said:
> > Trying to change that by breaking out a separate NTS-KE server would
> > introduce a lot of complexity when we could achieve the same result by
> > pointing the ntpd instances at a common key on a fileshare.
>
> That adds the fileshare to the security tangl
Hal Murray :
>
> I will be seriously disappointed if you drop that code.
>
> You need it to verify that you don't need it.
Interesting point. How do you account for the fact that nobody noticed
when it was accidentally disabled for six months, though? Definitely the
kind of thing I'd expect ei
Hal Murray :
>
> e...@thyrsus.com said:
> >> My strawman for REFCLOCKD is something like the touring test.
> >> You can't tell the difference by poking around with ntpq. (Maybe
> >> you don't get to poke too deep.)
>
> > It'd need its own UDP port.
>
> I don't understand. All I was trying to
Gary said:
> Think data center. The data center controls the LAN, but the customers
> control what is in the containers. Or the hacker that used the latest
> Wordpress bug to take over the contrainer. And breaking out of a container
> to infect the motherboard is not that hard.
I would assum
Eric said:
> Trying to change that by breaking out a separate NTS-KE server would
> introduce a lot of complexity when we could achieve the same result by
> pointing the ntpd instances at a common key on a fileshare.
That adds the fileshare to the security tangle and probably complicates the
sta
Gary said:
>> Otherwise, either do full validation or don't bother with NTS
>> at all. Pinning counts as full validation.
> I'd be happy if we had per host pinning instead of "noval".
How is per-host pinning normally implemented?
We have the option to use a local file of trusted/root certific
>> There is no security in the pool anyway, so let's put that discussion
>> aside for a while.
> I'd take exception with that statement. If the pool was upgraded to use NTS
> one way or the other, it _would_ provide some extra security over the status
> quo. It's a different kind of security th
43 matches
Mail list logo
