NTS dropping TLS 1.2

[Mark Atwood]

I think that our implementing this is a good reason for make a point release.

..𐑥𐑸𐑒
Mark Atwood <mark.atwood at 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 ntp at 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.
> 
> 
> 
>