Re: Interleaved Mode (Was: Re: Using Go for NTPsec)

On Tue, Jul 06, 2021 at 12:18:26PM -0500, Richard Laager via devel wrote: > On 7/5/21 8:38 AM, Eric S. Raymond via devel wrote: > > > There is a close-to-RFC to handle this area. "Interleave" is the > > > buzzword. I > > > haven't studied it. The idea is to grab a transmit time stamp, then >

Re: Clock tracking

On Mon, Mar 22, 2021 at 02:24:50PM -0700, Hal Murray via devel wrote: > > Since you mentioned PTP, can we use the PTP time stamping stuff to get better > time stamps for NTP packets? (without dragging in any/much PTP stuff) NTP can make use of some of the features that PTP hardware supports.

Re: OpenSSL 3.0.0

On Mon, Jun 15, 2020 at 11:54:57PM -0700, Hal Murray via devel wrote: > > They are up to alpha3. I've been trying it. > > I added a tweak to wscript to support this, and some notes in HOWTO-OpenSSL > That recipe also works for getting 1.1.1 on old systems so they can use NTS. > > - >

Re: OpenSSL quirk

On Fri, Oct 25, 2019 at 01:26:53AM -0700, Hal Murray via devel wrote: > I haven't seen any examples of OpenSSL on distros that are so old that they > don't support TLS 1.2 TLS 1.2 got added in 1.0.1, which was released in 2012. I'm guessing there are some old redhat versions that are still

Re: Garbled IPv6 printout

On Sat, Mar 30, 2019 at 08:05:41PM -0700, Hal Murray wrote: > > A sockaddr is not meant to store the address, ... > > But the API wants a sockaddr. >int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen); > There is no hint in the man page that an IPv6 address won't fit. > >

Re: Garbled IPv6 printout

On Sat, Mar 30, 2019 at 02:35:18PM -0700, Hal Murray via devel wrote: > I just pushed a fix. It was an interesting quirk. The API for accepet > includes a pointer and length to a place to put the IP Address of the remote > site. The type of that place is struct sockaddr. sockaddr is generic,

Re: CI: debian-oldoldstable

On Mon, Mar 25, 2019 at 04:00:23AM -0700, Hal Murray via devel wrote: > > I thought it had been removed. > > Job #183497467 ( https://gitlab.com/NTPsec/ntpsec/-/jobs/183497467 ) > > Stage: build > Name: debian-oldoldstable-refclocks > Trace: Err http://deb.debian.org oldoldstable-updates/main

Re: What's left to doo on NTS.

On Sun, Mar 03, 2019 at 03:30:53PM -0800, Gary E. Miller via devel wrote: > Yo Kurt! > > On Mon, 4 Mar 2019 00:19:44 +0100 > Kurt Roeckx via devel wrote: > > > > Actually getting timestamps from the NIC is fairly involved. The NIC > > > has its own clock

Re: What's left to doo on NTS.

On Sun, Mar 03, 2019 at 05:59:11PM -0500, Daniel Franke wrote: > On Sun, Mar 3, 2019 at 8:45 AM Kurt Roeckx via devel wrote: > > On Sun, Mar 03, 2019 at 05:23:31AM -0800, Hal Murray wrote: > > > > > > k...@roeckx.be said: > > > > If this is something y

Re: What's left to doo on NTS

On Sun, Mar 03, 2019 at 10:25:31PM +0100, Achim Gratz via devel wrote: > Kurt Roeckx via devel writes: > > I don't see how it can work with the current pool system. You look > > something up like pool.ntp.org and get some IP addresses. But none > > of those will have a certifi

Re: What's left to doo on NTS

On Sun, Mar 03, 2019 at 08:56:55PM +0100, Achim Gratz via devel wrote: > 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

Re: What's left to doo on NTS.

On Sun, Mar 03, 2019 at 05:23:31AM -0800, Hal Murray wrote: > > k...@roeckx.be said: > > If this is something you're worried about, this can be solved with the > > interleave mode, which was removed. > > How well does it work? It works great, the errors are much smaller when it's enabled. >

Re: What's left to doo on NTS.

On Sat, Mar 02, 2019 at 09:23:51PM -0800, Hal Murray via devel wrote: > *) There is actually one interesting point that authentication makes more > interesting. On receive, we get a time stamp when the packet arrives. We > can > take all day to inspect the packet and run authentication code.

Re: TLS Versions

On Wed, Feb 06, 2019 at 10:31:39PM -0800, Hal Murray wrote: > > k...@roeckx.be said: > > Please use 0 instead of TLS_MAX_VERSION, it means the same. I've marked > > TLS_MAX_VERSION for deprecation. > > Thanks for the heads up. > > Is there any documentation on that? (man page?) There is

Re: TLS Versions

On Wed, Feb 06, 2019 at 02:05:27PM -0800, Hal Murray via devel wrote: > > float mintls = 1.2; /* minimum TLS version allowed */ > float maxtls; /* maximum TLS version allowed */ > > Floats? The API to OpenSSL doesn't work in floats. We'll have to translate >

Re: mintls, maxtls, enclair, and cipher.

On Sun, Feb 03, 2019 at 03:15:55PM -0600, Richard Laager via devel wrote: > On 2/3/19 1:01 PM, Eric S. Raymond wrote: > > I guess it will have to be an empty string that disables encryption. > > I'm not sure if you wrote this before the recent messages on the NULL > ciphers. But you said you were

Re: Against certain proposed TLS client-side options

On Sat, Feb 02, 2019 at 05:52:25PM -0500, Eric S. Raymond via devel wrote: > Gary E. Miller via devel : > > On Sat, 2 Feb 2019 06:16:45 -0500 (EST) > > "Eric S. Raymond via devel" wrote: > > > > > NEVER CONFIGURE WHAT YOU CAN DISCOVER > > > > > > These are from nts.adoc: > > > > > >

Re: ntp_random - please check

nd to increase unpredictability. [Paul Dale, Benjamin Kaduk, Kurt Roeckx, Rich Salz, Matthias St. Pierre] (I guess I need to change this, the last line is not true anymore.) The RAND_keep_random_devices_open manpage can be seen here: https://www.openssl.org/docs/manmaster/man3/RAND_keep_random

Re: ntp_random - please check

On Fri, Jul 06, 2018 at 01:27:30PM -0700, Hal Murray via devel wrote: > Also, it didn't check the return code. That raises an interesting question. > What should we do if there isn't enough entropy? > > How much entropy is there in a typical system? Can a malicious user use it > all up?

Re: Why admin's do not trust daemons to do their own packet filtering (was Re: Resuming the great cleanup)

On Tue, May 29, 2018 at 03:15:15PM -0400, Eric S. Raymond via devel wrote: > [[interface]] > +interface+ [+listen+ | +ignore+ | +drop+] [+all+ | +ipv4+ | +ipv6+ | > +wildcard+ | 'name' | 'address'[/'prefixlen']]:: > This command controls which network addresses +ntpd+ opens, and > whether

Re: Crypto, passwords

On Fri, Jan 05, 2018 at 02:41:39PM -0800, Hal Murray wrote: > > > I have no idea how it's used in NTP. But I understand it's some kind of > > shared password? You should clearly look in how it's being used and if that > > actually makes sense. Maybe it needs more than just replacing the hash > >

Re: Crypto, passwords

On Fri, Jan 05, 2018 at 04:24:01PM -0500, Eric S. Raymond wrote: > Kurt Roeckx <k...@roeckx.be>: > > On Fri, Jan 05, 2018 at 10:04:44AM -0500, Eric S. Raymond via devel wrote: > > > > MD5 is no longer considered safe. > > > > Is SHA1 considered

Re: Crypto, passwords

On Fri, Jan 05, 2018 at 10:04:44AM -0500, Eric S. Raymond via devel wrote: > > MD5 is no longer considered safe. > > Is SHA1 considered safe? What other types should we test and/or suggest > > people use? > > No, SHA1 is no longer considered safe. The first collision was generated > early last

Re: All hands alert - NTPsec gets bad responses from Amazon NTP servers

On Sun, Dec 03, 2017 at 02:43:04PM -0500, Eric S. Raymond via devel wrote: > All hands alert. We have our first, or maybe second depending on how > you count, serious bug. About 33% of the time, NTPsec is eliciting bad > packets from Amazon time service. Classic does not have this problem. I

Re: seccomp ratsnets: crypto using threads

On Sat, Nov 25, 2017 at 01:26:18AM -0800, Hal Murray via devel wrote: > (gdb) bt > #0 0x76ebf104 in futex_wake (private=0, processes_to_wake=2147483647, > futex_word=0x76eaf618) at ../sysdeps/unix/sysv/linux/futex-internal.h:231 > #1 __pthread_once_slow (once_control=0x76eaf618,

Re: seccomp ratsnets: crypto using threads

On Sat, Nov 25, 2017 at 05:09:02AM -0800, Hal Murray wrote: > > k...@roeckx.be said: > > This means that when we initialize a global variable we use the > > pthread_once() function, which internally uses the futex to do that. It's > > not using threads itself, it's just making sure that if you

Re: Standard set of terms for precision, accuracy, related concepts.

On Mon, Apr 24, 2017 at 12:36:17PM -0400, Eric S. Raymond wrote: > Having almost recovered from post-viral fatigue syndrome, I have > enough energy to work now and am attempting to clear out my old > project-related mail. I'd like to have my decks cleared for the > face-to-face team meeting this

Re: _DATE__, version string, and distros

On Mon, Apr 17, 2017 at 06:41:01PM -0700, Hal Murray wrote: > I think we can kill two birds with one stone. > > The first step is to change the code that uses __DATE__ to use the time stamp > from autorevision. Have you seen https://reproducible-builds.org/specs/source-date-epoch/ ? Kurt

Re: Wildcard-socket simplification hits a wall

On Fri, Mar 31, 2017 at 07:30:05PM -0400, Eric S. Raymond wrote: > Kurt Roeckx <k...@roeckx.be>: > > > One might expect this to be available via a CMSG lookup into recmvsg's > > > per-package auxiliary headers, analogously to the way we now get the > > >

Re: Wildcard-socket simplification hits a wall

On Thu, Mar 30, 2017 at 12:06:36PM -0400, Eric S. Raymond wrote: > Head up, Mark! Policy issue. > > I fear the wildcard-socket simplification, last of our pre-1.0 major > ambitions, has just hit a wall. > > The problem is not with the code simplification itself. The problem is > that there is

Re: Crypto timings

On Sun, Jan 29, 2017 at 10:44:49PM +0100, Kurt Roeckx wrote: > On Sun, Jan 29, 2017 at 09:09:56PM +, Greg Rubin wrote: > > Mind running the timings with the legacy interfaces as well? We may > > determine that the speed benefits are outweighed by the risks and > > complex

Re: Crypto timings

On Sun, Jan 29, 2017 at 09:09:56PM +, Greg Rubin wrote: > Mind running the timings with the legacy interfaces as well? We may > determine that the speed benefits are outweighed by the risks and > complexities of an older API, but it would be good to have the data so we > can make an informed

Re: Timings for random

On Sat, Jan 28, 2017 at 12:48:34PM -0800, Gary E. Miller wrote: > Yo Hal! > > On Sat, 28 Jan 2017 12:39:02 -0800 > Hal Murray wrote: > > > Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz > > Stdlib: 100 calls to rand() took 0.021 microseconds each > > Sodium: 100 calls

Re: Hash function support, MD5 / SHA256, strawman proposal

On Fri, Jan 27, 2017 at 03:00:42PM -0800, Hal Murray wrote: > > fallenpega...@gmail.com said: > > How hard would the following be? > > Just go ahead and add SHA256 to NTPsec then Write an I-D modifying the NTP4 > > protocol documenting it. then Write a patch to NTP classic for it. > > (yes, I

Re: Current status of --enable-crypto

On Fri, Jan 27, 2017 at 03:42:09PM -0500, Eric S. Raymond wrote: > Daniel Franke : > > Where is this notion coming from that OpenSSL is going to drop MD5 or SHA1 > > support any time soon? That's inconceivable to me. > > I think it was either Achim Gratz or Kurt Roecx (I

Re: Crypto tangle

On Fri, Jan 27, 2017 at 08:38:06PM +0100, Achim Gratz wrote: > Eric S. Raymond writes: > > It depends on which MAC algorithms we want to support, a question I've > > opened > > in a recent email. It looks like libsodium's support for hash functions in > > our set is limited to SHA-2, so

Re: ✘sys_fuzz * ntp_random()

On Tue, Jan 24, 2017 at 10:38:50PM +0100, Achim Gratz wrote: > sys_fuzz (which whitens the quantization noise on the clock reading) > doesn't make a difference or you might not. But presumably Dave Mills > didn't put it in there just because he was trying to add useless code. So it seems to me

Re: sys_fuzzMime-Version: 1.0

On Wed, Jan 25, 2017 at 02:12:05AM -0800, Hal Murray wrote: > I think kernels went through 3 stages: > > Old old kernels were very coarse. They bumped the clock on an interrupt. > End of story. > > Old kernels use the TSC (or equivalent) to interpolate between interrupts. > (A comment from

Re: Precision and accuracy

On Fri, Jan 20, 2017 at 05:39:37PM -0800, Gary E. Miller wrote: > Yo Kurt! > > On Sat, 21 Jan 2017 01:23:47 +0100 > Kurt Roeckx <k...@roeckx.be> wrote: > > > On Fri, Jan 20, 2017 at 12:44:38PM -0800, Gary E. Miller wrote: > > > Imagine in front of you are

Re: Precision and accuracy

On Fri, Jan 20, 2017 at 12:44:38PM -0800, Gary E. Miller wrote: > Imagine in front of you are two handheld voltmeters, and a super > precision voltage source. So let me correct all those terms to what people normally use them for. You have a voltmeter those shows volt with 3 digits behind the

Re: libsodium mess

On Thu, Jan 19, 2017 at 02:40:08PM -0800, Gary E. Miller wrote: > > > I'm worried about 1 micro Second or less. And one should not > > > confuse accuracy with resolution. A PPS signal only has a > > > resolution of one Second, but can eaaily have an accuracy of 10 > > > nano seconds. > > > >

Re: libsodium mess

On Thu, Jan 19, 2017 at 01:00:50PM -0800, Gary E. Miller wrote: > Yo Kurt! > > On Thu, 19 Jan 2017 21:20:23 +0100 > Kurt Roeckx <k...@roeckx.be> wrote: > > > On Thu, Jan 19, 2017 at 02:30:35PM -0500, Eric S. Raymond wrote: > > > Gary E. Miller <g...@rel

Re: libsodium mess

On Thu, Jan 19, 2017 at 02:30:35PM -0500, Eric S. Raymond wrote: > Gary E. Miller : > > > - to fuzz the low-order bits of the clock. > > > > Hmm, can you expand on this a bit? Which clock? How much fuzz? > > Does this degrade anything? > > Whenever ntpd polls the system clock,

Re: libsodium mess

On Thu, Jan 19, 2017 at 01:32:20PM -0500, Eric S. Raymond wrote: > > INSTALL says: > > Debian: libsodium > > > > apt-get install on my debian box says: > > E: Unable to locate package libsodium > > Running Wheezy, I take it? It's libsodium-dev Kurt

Re: Replacing C

On Sun, Jan 08, 2017 at 04:53:57PM -0800, Gary E. Miller wrote: > Yo All! > > On Mon, 9 Jan 2017 01:30:30 +0100 > Kurt Roeckx <k...@roeckx.be> wrote: > > > > That said, I continue to admire your cut right to the heart of the > > > issue. ntpd spends enoug

Re: Replacing C

On Sun, Jan 08, 2017 at 03:51:13PM -0800, Hal Murray wrote: > > We should measure the time from grabbing the time stamp to sending the > packet. That might include some crypto. We might get better results by > adjusting the time stamp to compensate for that. Adjusting the timestamp to when

Re: Replacing C

On Sun, Jan 08, 2017 at 06:02:36PM -0500, Eric S. Raymond wrote: > Hal Murray : > > We don't care about the timing in most of the code. The only critical > > section is the chunk between grabbing the time and sending the packet. > > That > > chunk is likely to involve

Re: Replacing C

On Sun, Jan 08, 2017 at 02:37:43PM -0800, Hal Murray wrote: > > >> OTOH, if the OS is time stamping packets, and PPS, for the ntpd daemon > >> then the daemon can tolerate 'some' jitter. > > > In normal operation we can expect lots of pairs of small allocations at UDP > > datagram sizes with

Re: I'm off to learn Rust

On Sun, Jan 08, 2017 at 03:59:51PM -0500, Eric S. Raymond wrote: > Susan and I have decided to revive an old idea we were originally going > to do in Python and implement it in Rust instead - a better IRC > server. Susan has years of field experience with IRC servers written > in C and says

Re: Replacing C

On Sun, Jan 08, 2017 at 02:12:21PM -0500, Eric S. Raymond wrote: > Kurt Roeckx <k...@roeckx.be>: > > I had a quick look at some of the stats of my peers over internet, > > and most actually seem to have an average jitter in the order of > > around 100 microseconds. Some

Re: Replacing C

On Sun, Jan 08, 2017 at 07:11:22PM +0100, Kurt Roeckx wrote: > On Sun, Jan 08, 2017 at 09:48:09AM -0500, Eric S. Raymond wrote: > > On the other hand, I don't consider requiring a runtime to be an > > *intrinsic* disqualifier. The real question is, in my view, the > > 9

Re: Replacing C

On Sun, Jan 08, 2017 at 09:48:09AM -0500, Eric S. Raymond wrote: > On the other hand, I don't consider requiring a runtime to be an > *intrinsic* disqualifier. The real question is, in my view, the > 95th-percentile length of latency-inducing stop-the-world stalls. > If it's below 100

Re: New blog draft on the TESTFRAME debacle

On Sun, Jan 08, 2017 at 06:35:58AM -0800, Hal Murray wrote: > > >> Using the term PLL. > > But that's how the code is organized. In the absence of a PLL it doesn't > > slew. Or am I missing something here? > > (at least) One of us is confused. > > The text from the blog: > > There are two

Re: The end of the beginning is in sight

On Fri, Jan 06, 2017 at 12:14:35PM -0500, Eric S. Raymond wrote: > and the other is ripping out all > the interface-scanning stuff so we lose the dependency on > getifaddrs(3) and use wildcard interfaces only. Are you sure this is going to work? As far as I know there are (or were) good reasons

Re: Recent NTP pool traffic increase

On Sat, Dec 17, 2016 at 07:03:16PM -0800, Gary E. Miller wrote: > Yo All! > > On Sat, 17 Dec 2016 17:56:32 -0800 > "Gary E. Miller" wrote: > > > # tcpdump -nvvi eth0 port 123 |grep "Originator - Transmit Timestamp:" > > > > And I do indeed get odd results. Some on my local

Re: fuzzing NTPsec with afl

On Mon, Nov 21, 2016 at 02:11:12PM -0900, Royce Williams wrote: > > If those minimal changes are turned into a compile-time option, this > would enable adding fuzzing to the rolling test suite, perhaps using > some of Susan's resources. Google also provides resources via oss-fuzz. If you can

Re: Fw: [Git][NTPsec/ntpsec][master] 2 commits: Some u_long -> unsigned int changes.

On Fri, Sep 23, 2016 at 01:41:07PM -0500, Joel Sherrill wrote: > On Fri, Sep 23, 2016 at 1:08 PM, Gary E. Miller wrote: > > > Yo Eric! > > > > > > > These are valid because the invention and major uses of u_long in this > > > codebase predate the 64-bit transition - it may look

Re: How much do we care about high-load scenarios?

On Wed, Sep 14, 2016 at 06:00:45PM -0400, Eric S. Raymond wrote: > Dan Drown : > > Quoting "Eric S. Raymond" : > > >Achim Gratz : > > >>…or move the refclocks out of ntpd altogether and use some shared memory > > >>or mailbox system to have

Re: How much do we care about high-load scenarios?

On Wed, Sep 14, 2016 at 04:40:57PM -0500, Dan Drown wrote: > > This page from cloudflare does a nice job of describing the limitations of a > single process UDP receive model: > https://blog.cloudflare.com/how-to-receive-a-million-packets/ > > The limit they hit with their hardware was around

Re: Possible abuse from fetching the leap second file

On Mon, Aug 15, 2016 at 08:37:14AM -0400, Eric S. Raymond wrote: > Hal Murray : > > > > e...@thyrsus.com said: > > > While I accept this as a general principle, is there anything about the > > > new > > > ntpleapfetch that inflicts a heavier load than the old

Re: Use of pool servers reveals unacceptable crash rate in async DNS

On Sat, Jun 25, 2016 at 06:13:56PM -0400, Eric S. Raymond wrote: > Hal Murray : > > > > e...@thyrsus.com said: > > > 1. Apply Classic's workaround for the problem, which I don't remember the > > > details of but involved some dodgy nonstandard linker hacks done through >

Re: We need a release checklist

On Mon, May 23, 2016 at 02:38:42PM -0700, Hal Murray wrote: > > fallenpega...@gmail.com said: > > There should be a tag in gitlab. If there is not, it is my mistake, and I > > will fix it this evening. ..m > > k...@roeckx.be said: > > There are also no releases on

Re: Release of NTPSec 0.9.3

On Mon, May 23, 2016 at 08:51:06PM +, Mark Atwood wrote: > There should be a tag in gitlab. If there is not, it is my mistake, and I > will fix it this evening. ..m There are also no releases on ftp://ftp.ntpsec.org/pub/releases/, 0.9.1 is the latest. Kurt

Re: What is a release?

On Mon, Mar 21, 2016 at 09:47:27PM +0100, Kurt Roeckx wrote: > A few things that I think you can improve is a download link > somewhere on the website. It would also be nice if you provide a > SHA256 sum of that, and that someone signs the release. You probably also want to make the

Re: SIGINT, longjmp

On Tue, Jan 26, 2016 at 01:07:04PM -0800, Hal Murray wrote: > > The problem is that somebody is masking off SIGINT. It works if I replace > setjmp+longjmp with sigsetjmp+siglongjmp. > > The SIGINT handler was getting called with SIGINT masked off. That seems a > bit strange. It was coming

Re: SIGINT, longjmp

On Tue, Jan 26, 2016 at 01:38:52PM -0800, Hal Murray wrote: > > k...@roeckx.be said: > > It's not clear to me when this longjmp() is called. But if changing to > > siglongjmp() fixed it, it seems the signal handling got changed in between? > > It's called from the ^C signal handler. It's the