Are we going to have a no-NTS-KE build option?

[Eric S. Raymond]

James Browning via devel <devel at ntpsec.org>:
> > If we did away with shared key authentication, we could potentially do
> > away
> > with needing libcrypto.  Aside from authentication, we also use
> > RAND_bytes()
> > so we would need to substitute something for that.
> 
> Funny, I thought -lssl needed libcrypto as a base. IIRC the current NTS
> draft does not support mode 6. So if authenticated UDP control/monitoring
> sessions are desirable you still need to keep symmetric key support.
> 
> I might be wrong though.

James, you are correct.  Privileged ntpq functions require the crypto.

Hal, I don't see requiring libcrypto/lssl as a problem.  At this point I'm
more interested in reducing our range of build variants than I am in snipping
off dependencies towards a (rather theoretical) crypto-less build.

The context for this choice of priorities is that a maximal build of
NTPsec is *tiny* by today's standards, and was so even before we
ripped out 75% of the old codebase.  Thus the classical reason for
stripped-down variant builds - holding down binary sizes - no longer
applies even on RasPi class SBCs or lower.

Accordingly, squeezing complexity out of our build system even at the
cost of putatively "oversized" binaries starts to look like a good trade.
I've even contemplated abolishing no-refclock builds, though I haven't
been able to make myself do that yet - my old-time reflexes are a bit too
strong for that...

Besides the complexity reduction, I have an eye forward on a possible
port to Go. Go offers many, many advantages, but one thing it does
*not* have is a preprocessor and ad-hoc code conditionalization.  Variant
builds are still possible using Go's build-tag system but not at the kind
of fine granularity C supports.  To support conditional linking of reclocks,
for example, we will need to write a custom code generator that builds a
driver dispatch table. 

OTOH, I like the idea of getting rid of shared-key authentication.  Not to
reduce binary size or build dependencies but to reduce global complexity and
attack surface.  But the path forward to *that* has to look like this:

1. Get NTS working.

2. Write a new control mode, functionally like mode 6, that uses NTS
rather than shared-key crypto.  I wouldn't mind doing this, because
the Mode 6 message format is an ugly mess by today's stabdards - I
would very cheerfully replace it with an implementation that tosses
JSON datagrams back and forth.  Could be done without changing ntpq's
user-visible interface, I've scoped this out in my head.

3. Drop shared-key crypto entirely.  Big win for code removal but
means classic ntpq could no longer talk to an NTPsec installation or
vice-versa.  We *probably* don't care technically, the bigger issue
would be about about preserving backard compatibility for conservative
installations.

Point is, dropping libcrypto is a couple of architectural steps away
from where wee are now.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.