On 4/22/22 02:08, Hal Murray wrote:
+1 to NOT making this a knob.
Would you please say more.
It would be invisible unless you go looking for it.
Are you against unnecessary knobs in general?
Yes.
If I had pushed this code a
month or 3 ago when we weren't discussing a release or wildcards, would you
have spoken up against it?
If I saw it, yes. I did speak up about the documentation change. That
one is concerning in the same _way_, but to a far lesser _degree_.
Granted I'm at a small shop, but I have a lot of operational experience
with TLS. I've configured TLS in different daemons for a whole bunch of
protocols. For a non-exhaustive list:
* HTTPS (Apache & nginx)
* FTP (ProFTPD)
* IMAP/POP (Dovecot)
* SMTP (Postfix and Exim & sendmail before that)
* syslog (rsyslog)
* IKE VPNs (strongswan on Linux & pfSense; Cisco ASAs)
* NTS (NTPsec) of course
They all work pretty similarly:
* For a server, you configure the key, certificate, and chain (sometimes
one file, sometimes two, sometimes three).
* You can generally configure the cipher lists on both clients and
servers (though I generally only bother with that on servers).
* Servers (and only servers, given how the protocol works) often have an
option to whether to "honor" (read: force) the server's cipher _order_.
The alternative being to use the client's cipher _order_.
* When you're acting as a client, you can generally configure the root
CAs in some fashion.
I'm not against adding the typical options to daemons. And in fact, I've
worked with upstreams to do just that. In the case of rsyslog, I had to
wrap with stunnel for a while due to some limitation. I worked with
upstream and/or Ubuntu to get that fixed. In the case of ProFTPD, it
didn't have the TLS1.3-specific configuration, I requested that as a
feature, which they did add. I also worked with ProFTPD as well as
WinSCP (and reported issues to another client or two) to make SNI on
FTPS viable in the real world.
I've also attempted to configure TLS in a daemon (and client) where it
was clear the daemon author had absolutely no idea what they were doing.
In that case, they wanted you to configure a CA (yes really!) and the
daemon would generate server certificates on demand. That was clearly
insane. In that case, I left them speaking plaintext and wrapped the
connection with stunnel on both sides. This glaring issue left me very
concerned about the quality of this daemon's implementation generally.
Unfortunately, it's the only FOSS solution in that problem space, so I
had to keep using it.
You adding a knob about wildcards (and your recent documentation change)
are red flags for me. While they certainly aren't as bad as the "give me
a CA" example above, when you're doing things that deviate from widely
established practice across different projects, I get concerned. It
suggests to me that A) you don't know what you're doing in this space,
and/or B) you're building what I call a "science fair project"
(something fun to explore the technology that has little to no
production use case).
If you don't have a lot of experience in this area, that's totally fine.
There's no shame in that. Not being a TLS expert doesn't take anything
away from your experience in the time & NTP space generally. Please
survey the landscape of existing daemons / other people to get a feel
about what TLS options are normal.
If you want to build a science fair project, by all means do that. But
not in master for a critical daemon like ntpd.
There may be cases where ntpd needs to deviate from established
practice. For example, maybe we need some knobs related to
bootstrapping, due to the unique role that ntpd plays (i.e. getting the
time correct so that certificate NotBefore/NotAfter can be verified).
I've talked about that at length before. So I'm not 100% against ntpd
having a TLS option that isn't in other daemons, but it needs to be
justified by something unique to ntpd/NTS.
I see no reason that ntpd specifically should have different wildcard
handling than typical TLS clients for various protocols.
Now, I certainly understand there are security trade-offs inherent in
wildcard certificates. And a lot of the benefit is lost once you're no
longer dealing with certificates manually and are instead automating
their issuance. Likewise for paid vs free. Here's what looks to be a
decent write-up (and some good comments there):
https://gist.github.com/joepie91/7e5cad8c0726fd6a5e90360a754fc568
But none of that feels ntpd-specific to me.
I wonder how many unnecessary features there are in the current code base.
A big part of the reason for NTPsec was removing unnecessary cruft from
NTP Classic.
--
Richard
_______________________________________________
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
