Getting ready for a release, wildcards

[Richard Laager]

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