I think that our implementing this is a good reason for make a point release.
..π₯πΈπ Mark Atwood <mark.atw...@ntpsec.org> Project Manager of the NTPsec Project +1-206-604-2198 On Mon, Mar 23, 2020, at 01:24, Hal Murray wrote: > > A new version of the draft RFC is available: > https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/ > > They decided to drop support for TLS 1.2. Details way down. > > They also tweaked the TLS export string used to make client-server keys. > That > will break things if the client and server don't use the same one, aka > everybody has to update in sync. There is no way to detect the change. The > symptom will be lack of response. Stay tuned for more info, maybe a flag day > announcement. > > ------------ > > OpenSSL has dropped support for older versions that don't support TLS 1.3. > That was roughly the start of 2020. There used to be many more OSes that > were > still shipping old versions of OpenSSL. Most of them upgraded. A few > haven't. > > The ones I know about that haven't upgraded are older (but still supported) > versions of CentOS, NetBSD, and probably Debian and Raspbian. > CentOS runs old/stable code. People running their old version are unlikely > to > be interested in NTPsec or NTS. > NetBSD is getting ready for a release that will drop support for the current > old/broken version. > > I don't have an old version of Debian handy. I do have old Raspbian which > usually tracks Debian. It has an old OpenSSL. > > I don't know about other OSes. > > > You can tell if you have older clients by scanning your log files for > "TLSv1.2". The server will say something like: > 19 Mar 14:27:31 ntpd[30185]: NTSs: NTS-KE from 192.168.1.29:65366, Using > TLSv1.2, ECDHE-RSA-AES256-GCM-SHA384 (256), took 0.015 sec > > If your client is talking to older servers, it will say something like: > 22 Mar 06:42:19 ntpd[679]: NTSc: Using TLSv1.2, AES256-GCM-SHA384 (256) > > Our current code supports TLS 1.2 with a handful of ifdefs. (Actually, > mostly > #if checking the version number.) > > We can do several things: > 1) clean out the ifdefs that make things work with older versions of > OpenSSL. > That is drop support for systems that haven't upgraded their OpenSSL to a > supported version. > 2) leave things alone, ignore the RFC. > Or maybe add some nasty warning messages > How long? > 3) make a configure option to disable NTS so that NTPsec builds on older > OSes but doesn't support NTS. > > I propose option 1. Simple and clean. I don't think we will drop many > systems. > > -------------- > > (From n...@ietf.org) > > - No TLS 1.2 > During this work, it became apparent that keeping support for TLS 1.2 > and correctly covering for the differences between TLS 1.2 and TLS 1.3 > would be a lot of work, with the risk of getting something wrong or > missing on important issues, in the specification or in the > implementations. > > The last time the issue of 1.2 support was up for debate, there were > some operating systems that would not support TLS 1.3, and there was a > concern that this would impair the protocol adoption rate. Today most > (all?) major operating systems do have TLS 1.3 capable libraries in > their later versions. > > > > > -- > These are my opinions. I hate spam. > > > > _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
