Re: [chrony-dev] Multiple NTS keys on server
On Tue, Feb 2, 2021 at 5:04 PM Miroslav Lichvar wrote: > > I'd like to add support for multiple keys to the NTS server to enable > virtual hosting as is common with web servers. A use case which I > thought it could enable would be servers that run only for a limited > time to support different products or versions of the product (like an > OS), where each has its own certificate included in the installation > and is fully trusted to avoid the issues with wrong or missing RTC and > failing time checks in certificate verification. This would allow the > server keys to be rotated as the products/versions reach their > end-of-line and it would also limit the number of devices that need to > be updated/fixed when a key is compromised. > > I'm not sure how it should be configured. I see the following options: > > 1) allow multiple files to be specified in ntsservercert and > ntsserverkey directives > - long lines are not great for inspection and editing > - maximum number of keys/certs is limited by the maximum line length > 2) allow multiple ntsserverkey/ntsservercert directives > - sensitive to order (few directives in chrony have this property) > 3) allow glob patterns in ntsserverkey/ntsservercert directive > - certs and keys need to have the same naming scheme to pair correctly > > I think 1) is just not acceptable. From 2) and 3) I'm not sure what is > better. > > For example: > > ntsservercert /etc/pki/tls/certs/nts-1.example.net > ntsserverkey /etc/pki/tls/private/nts-1.example.net > ntsservercert /etc/pki/tls/certs/nts-2.example.net > ntsserverkey /etc/pki/tls/private/nts-2.example.net > ntsservercert /etc/pki/tls/certs/nts-3.example.net > ntsserverkey /etc/pki/tls/private/nts-3.example.net > > vs > > ntsservercert /etc/pki/tls/certs/nts-*.example.net > ntsserverkey /etc/pki/tls/private/nts-*.example.net > > Any suggestions? You already have subfile inclusion with globbing like "include /etc/chrony/chrony.d/*.conf". Which means users could keep each individual cert-config small and simple - also less in-file-edit if you programmatically place them. But for that to help in this case it would have to be option (2) of your list. Also TBH, (2) and (3) are not mutually exclusive - so you could do a combination of the two. But if I'd have to select just one I'd personally pick (2) for helping me with the split-config-files approach. Just an opinion while doing the morning-mail-check - kind regards, Christian > -- > Miroslav Lichvar > > > -- > To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with > "unsubscribe" in the subject. > For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the > subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
[chrony-dev] Multiple NTS keys on server
I'd like to add support for multiple keys to the NTS server to enable virtual hosting as is common with web servers. A use case which I thought it could enable would be servers that run only for a limited time to support different products or versions of the product (like an OS), where each has its own certificate included in the installation and is fully trusted to avoid the issues with wrong or missing RTC and failing time checks in certificate verification. This would allow the server keys to be rotated as the products/versions reach their end-of-line and it would also limit the number of devices that need to be updated/fixed when a key is compromised. I'm not sure how it should be configured. I see the following options: 1) allow multiple files to be specified in ntsservercert and ntsserverkey directives - long lines are not great for inspection and editing - maximum number of keys/certs is limited by the maximum line length 2) allow multiple ntsserverkey/ntsservercert directives - sensitive to order (few directives in chrony have this property) 3) allow glob patterns in ntsserverkey/ntsservercert directive - certs and keys need to have the same naming scheme to pair correctly I think 1) is just not acceptable. From 2) and 3) I'm not sure what is better. For example: ntsservercert /etc/pki/tls/certs/nts-1.example.net ntsserverkey /etc/pki/tls/private/nts-1.example.net ntsservercert /etc/pki/tls/certs/nts-2.example.net ntsserverkey /etc/pki/tls/private/nts-2.example.net ntsservercert /etc/pki/tls/certs/nts-3.example.net ntsserverkey /etc/pki/tls/private/nts-3.example.net vs ntsservercert /etc/pki/tls/certs/nts-*.example.net ntsserverkey /etc/pki/tls/private/nts-*.example.net Any suggestions? -- Miroslav Lichvar -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-dev] Frequency transfer in NTP
On Thu, Jan 28, 2021 at 11:31:47AM -0800, Bill Unruh wrote: > Not sure how, since there is no frequency standard. Frequency is seconds per > second. But for this not to be a tautalogy, what are the two seconds in that > refering to? Anyway, yes it is certainly interesting. It is also slightly > worrying that chrony has that oscillation as one goes up the stratum level. > Can it go unstable? Certainly there is no evidence at stratum 4, but could > stratum 10 say go unstable? I ran a few tests to see how it looks at stratum 10. The oscillation can get very bad, but I don't think it can break completely, e.g. get to a state from which it cannot recover. https://fedorapeople.org/~mlichvar/ntpresponse/chrony44.png It seems the impact of the step can be reduced if the polling interval is allowed to change (minpoll < maxpoll). As the step causes the client to drop to a shorter interval, it has a chance to get over the overshoot before it's polled by its own client. The responses in the chain can be staggered and so they don't pile on top of each other as much, but it oscillates for a longer time. https://fedorapeople.org/~mlichvar/ntpresponse/chrony46.png I have also done some testing over a longer interval, with no artificial steps, to show the improvement with enabled frequency transfer. This is a table with the RMS offset in microseconds measured at all strata. At stratum 10, there is an improvement of a factor of 3. stratum no-freq freq 2 11.712.0 3 18.115.4 4 24.717.2 5 30.120.7 6 40.122.5 7 50.425.9 8 64.226.9 9 77.129.0 10 91.731.4 -- Miroslav Lichvar -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
