Re: NTS next steps
> 2. Put together client-side NTS support. This mainly means filling in >ntpd/nts.c, as I have already written required the hooks into the >protocol machine. We need code to generate cookies. And test code to pack, encrypt, decrypt, and unpack. (No byte swapping - we get back what we send.) We need code to pack/unpack/byte swap extension fields, and authenticate requests and check authentication and decrypt responses. I will go look at your hooks to see if the API looks reasonable. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Going forward with NTS
e...@thyrsus.com said: > Don't you think it makes sense to very our client code against a known-good > implementation first, though? Maybe. Maybe not. If we had a known-good server and somebody who was sitting next to me knew all about it and was prepared to help debug, sure that would be a good way to go. But I don't agree with your "first". I think we know enough about what we need to do that the risk of wasting a lot of effort because we got a bogus program structure is low so I don't see the need to do that testing early. Devil's advocate hat on. We should debug as much as possible independently and then see if they inter-operate. If not, we should figure out why. If the people reading the specs got different answers, there is probably a section that needs tweaking to avoid an ambiguity. Here is an alternative sequence... Write hack program to call NTS-KE-server, send request, get answer, decode and print answer. Debug that program on existing remote server. Use it to debug our server. ... That program would probably be handy for debugging so maybe we should write it anyway. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Going forward with NTS
e...@thyrsus.com said: > I think we'd best completely avoid writing an NTS-KE server until we have > tested our client side against one of the two existing server > implementations. Then we have to learn how to drive the existing implementations, and learn enough about how they operate so we can insert printfs for debugging. I think I'd be happier working with code and people I'm familiar with. We can bring our client and server up in steps. Dummy KE client and server - just do handshake cookies - pack and unpack via tests KE server returns cookies KE client returns cookies to NTP client NTP client sends cookies to NTP server. NTP server decodes/processes cookies. NTP server sends back new cookies. We can get a layer of parallelism by using dummy cookies. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Going forward with NTS
> Please open an issue. It's not something I can give priority to at the > moment. Done. > In fact, it's not strictly speeking something we need to fix until we're > worrieed about using a C library other than glibc. It does some weird things > under the hood to make stdio operations thread-safe. msyslog is mostly not stdio so that won't help much. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Going forward with NTS
Thanks. Please make sure this gets on your list. Do you have a list for NTS or should I make an issue for it? I haven't looked at the code recently. This seems like a good opportunity for a review and cleanup and/or the addition of a good comment discussing the thread area. I think the current code writes the date and payload as separate chunks. Maybe the "ntpd[9149]:" is another chunk. Each line can go to several places: syslog console log file I think the current code doesn't support syslog and log file but I'd like to fix that. syslog adds date and prog[pid]. We want the date on the console, but the prog[pid] would just be clutter We want data and prog[pid] in the log file. If we don't need to skip over the prog[pid] for the console, we could just make one string with everything and skip over the front stuff for syslog. If we want to skip prog[pid], we can use writev(). Do we want to include the thread ID if not the master thread? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Going forward with NTS
Eric: > I plan to post a detailed analysis and task list later today. I'm working on > that now. I have hack code that makes a TLS connection and verifies certificates. If/when things calm down, I'll start folding it in. ntpd/ntpd.c has a main() in it. Is the plan to have NTS-KE-server packaged as a separate program? Why not a separate thread in ntpd? That seems like it would be simpler to admin for the common case. More optional parameters: how many KE-server threads do we want? how long should a server thread wait for data? There is the standard DoS attack problem on any system using TCP. Is there a good writeup on that we can point to? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Going forward with NTS
> I plan to post a detailed analysis and task list later today. I'm working on > that now. One thing that would be very nice is for msyslog to be thread safe. If we use a lock, we need to be able to recover in case we crash within msyslog while the lock is held. I'm not enough of a Unix file system wizard. Are there any guarantees about multi-threaded writes to the same file not getting scrambled? Will it work if we buffer everything into a big buffer and do a single write? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Amusing implications
> Now, if it doesn't meet our accuracy thresholds, that's another story. Do we have any accuracy standards? Given the screwups that can happen with bufferbloat, I'll bet it works much better than some network connections. It would be interesting to measure the delays on dial up lines. I wonder if they are symmetric or if they get converted to VoIP with typical who-knows type routing. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Should two-digit years be fatal to a refclock?
> My instinct in situations like this is to try to find a way to reduce the > combinatorial complexity of the problem. Which is why I'm attracted to > disqualifying any time source that truncates years. What's wrong with just adding 2000 to 2 digit years? We are in the 2000s now so we don't have to consider the 1900 case any more. I'd be happy to reconsider dropping support for 2-digit drivers in another 30 years. There is another roll-over consideration we should add to the list. That's the GPS 1024 week tangle. Where should that list live? 2 digit years 32 bit time_t 1024 week GPS -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Docs we will need
Richard said: > That said, on a Pi, if you write the time to a file on shutdown, then you > will be accurate enough for certificate checks to pass on reboots and outages > shorter than a couple months. Eric said: > Thanks, it's important to know the order of magnitude of the slack there. At shutdown probably isn't good enough. You don't get clean shutdowns on a site wide power loss. Maybe shutdown and a weekly/monthly cron job. Are there other files we can use? log files? They are all based on normal activity using the system clock so if the clock is off, they all get polluted. Maybe the ntpd drift file? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Docs we will need
Another complication with getting started after a building/site wide power loss is that getting time needs DNS and the local caching DNS server may be waiting for valid time. We may need a local cache - /etc/hosts? and a cron job to keep it up to date. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Should two-digit years be fatal to a refclock?
> (I thought the RasPi stored a timestamp on a clean shutdown, then reads it
> back at boot time, so time is usually not actually zeroed. But I don't know
> that, and no such fallback is mentioned aty that link.)
You can check that by looking at your syslog and/or ntp log files.
The details may depend on the OS/Distro.
>From a clean reboot on Fedora, Pi 3.
2 Feb 17:46:14 ntpd[489]: PROTO: 192.168.1.33 unlink local addr 192.168.1.71
->
2 Feb 17:46:14 ntpd[489]: PROTO: 0.0.0.0 001d 0d kern kernel time sync
disabled
11 Jan 03:41:06 ntpd[498]: CLOCK: leapsecond file ('/usr/share/zoneinfo/leap-se
conds.list'): stat failed: No such file or directory
11 Jan 03:41:06 ntpd[498]: INIT: Using SO_TIMESTAMPNS
...
11 Jan 03:42:20 ntpd[498]: PROTO: 192.168.1.3 b01a 8a sys_peer
11 Jan 03:42:20 ntpd[498]: PROTO: 0.0.0.0 c01c 0c clock_step +1951552.134334 s
2 Feb 17:48:12 ntpd[498]: CLOCK: time stepped by 1951552.134334
2 Feb 17:48:12 ntpd[498]: CLOCK: time changed from 2019-01-11 to 2019-02-02
2 Feb 17:48:12 ntpd[498]: PROTO: 0.0.0.0 c015 05 clock_sync
2 Feb 17:48:17 ntpd[498]: PROTO: 0.0.0.0 c018 08 no_sys_peer
Looks like it's off by almost a month.
> If the zero date was in the last century and your local refclock only ships a
> two-digit date, you have a problem. NTP will cheerfully "correct" the time
> into the last century. This is a real problem case with RasPis or
> BeagleBones using a vanilla NMEA GPS. So much for standalone operation,
> which we now advertise as an NTPsec feature.
Didn't we discuss this a year or 3 ago? I thought the solution is to pivot
around the build date of ntpd. There is a ntpcal_get_build_date() in
libntp/ntp_calendar.c
It's called by refclock_trimble, refclock_nmea, and libntp/systime.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Docs we will need
We'll need documentation to help people setup things to use NTS. I think the client side will be simple, a sentence or two. The server side is more complicated. I think we'll want HOWTO level docs. Probably one using Lets Encrypt and maybe others for when you already have a certificate infrastructure and maybe one for self signed. - There is a corner case that doesn't get a lot of publicity - how to get off the ground. That's going to get more complicated with certificates. Here is an example that I've encountered. Suppose you have 6 servers with minsane set to 3 all using each other. When recovering from a power failure everybody ends up waiting for everybody else to get started. - Years ago, I worked for DEC in Palo Alto. Power in our corner of the city was "interesting". During the summer, our admin guys got a lot of practice in getting everything going after a power failure. There was a sheet in the machine room with an ordered list of steps. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: mintls, maxtls, enclair, and cipher.
> The > "enclair" > option is intended to disable crypto negotiation so certificates are not > required and traffic in sent en clair. Please verify with a TLS wizard that you can do what you are describing with OpenSSL. I've poked around a bit and don't know how to do that. I think you get an error if client/server can't find a matching crypto algorithm. I don't know how to say no-crypto. It sounds like the sort of operational bug-attractor that you would like to stamp out. It's easy to setup a junk self-signed certificate for the server. We could ship one to enable testing -- or waf could generate one on the fly. I don't know if the server can run without a certificate. Seems like a reasonable request, but a quick search found several questions without any answer. It's easy for the client to not check the certificate. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: C2S/S2C lifetime
Gary said: > The whole point is that the client knows the C2S and S2C. Otherwise he can > not key a session to the NTPD server. That is the plaintext. And he has the > cookie, with the algorithm use to make it. That is the ciphertext. So if the client knows the C2S and S2C, what is he trying to learn by attacking? He already knows his C2S and S2C so there is no point in attacking those. Knowing them doesn't help him attack somebody else's C2S/S2C. The server's K does get rotated so we don't need a way to force that. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
C2S/S2C lifetime
Gary said: > Nothing says that a single cookie could not be used by a farm of clients to > push the cookies per second into the thousands. > Then add that this is millions of know plaintext and known ciphertext pairs > That is not what the key reuse calculations assume. I'm missing a step. How are you getting known plaintext/cyphertext pairs? If an idiot gets a C2S/S2C pair and then sends zillions of packets, he exposes lots of traffic for his keys. Don't do that. If an attacker captures a cookie by spying on the wire, what can he do with it? He doesn't know the C2S so he can't use that cookie in new packets. He can replay the whole packet. That will generate new cookies/cyphertext but doesn't get any plaintext. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Are we thrashing?
If so, how can we improve things? The signal to noise on the mailing list has been pretty low recently. In hindsight, I'm sure I've contributed more noise than I would like. Note that even Eric is pushing code with warnings. --- One thing that I find helpful is to scan the rest of my inbox before replying. And maybe wait a few minutes to see if somebody else will clarify things. Another thing that might help is to keep the time scale in mind. What do we need for first ship? What can wait? How much do we need to think about issues that can wait to make sure we don't paint ourselves into a corner? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Cypher sets
Gary said: > Remember, the cipher sets are runtime dynamic. They can change under you in > an instant. So replace startup time with runtime. How does that work? Once a program is running, it's linked to a specific libsss and libcrypto. You can update the installed versions on disk but the program keeps using the version it started with. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Rekeying C2S and S2C is not necessary
Gary said: > Really? So unlimmited numbers of packets with identical C2S, S2S and master > key, differing only int ehnonce is not a problem? > Pretty much every crypto algorithm I know of has a recommended maximum number > of uses. Allowing these two to be used unlimited times is violating absic > crypto principles goint back to well before how Enigma, and other ciphers, > were broken. Correct. But they picked an algorithm with a large recommended max. If you do the math, it's conservatively longer than a client will stay up. >From mail last night: -- The per client-server pair of keys, C2S and S2C don't roll over as long as the connection works reasonably well. I asked about key lifetime on the NTP list and Daniel said we don't have to worry about it. https://mailarchive.ietf.org/arch/msg/ntp/lV74s2I97P8ncJdjsIKvlcAgEG0 > The recommendation for AES-SIV is to encrypt no more than 2**48 > messages under the same key. At one message per second that's almost 9 > million years. If you (unwisely) use AES-GCM instead, where the > recommended limit is 2**32 messages, that's still 136 years. -- 9 million years isn't the heat death of the universe, but it's long enough that we don't need to worry about it. Eric said: >>> What you almost need is a cookie extension to trigger a rekeying >>> periodically. >> Yes. Sad the Proposed RFC is silent on the subject. Seems a gaping >> hole to me. > Would you please add this to the nts.adoc list of issues we need to bring up > at the WG meeting. No! -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntp.conf changes for NTS
James Browning said: > IIRC the previous key is kept for a rotation. Unless you are using something > like poll 14+ it shouldn't be a problem. Correct. That's for K, the key the server uses to encrypt/decrypt part of a cookie. The client doesn't know anything about that key. But there is another pair of keys: C2S and S2C. They are used to authenticate and encrypt traffic between client and server. There is no explicit mechanism to roll them over - nor is there a need for one. In order to avoid tracking, cookies are not reused. Normally, the client has 8 cookies. For each NTP request-response exchange, the client sends a cookie and gets back a new one. If a packet gets lost, the client only has 7 unused cookies. On the next request, it says "PS: please send me an extra cookie." If 8 packets in a row are lost, the client will be out of unused cookies. At that point, it can either reuse cookies or go through NTS-KE again to get new cookies. NTS-KE will also refresh C2S and S2C. But if no packets are lost, C2S and S2C will be used forever. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntp.conf changes for NTS
> Yes, you'd need implausible to impossible lifetimes of the client/server > pairing for these to ever become a problem. But again, when key rollover > gets implemented as indicated in the RFC, those will stop being useful on the > second rollover. What stops being useful when K rolls over is old cookies. C2S and S2C are used to authenticate the packets and also to encrypt new replacement cookies from server to client. There is no roll over mechanism for C2S or S2C. They get refreshed if you go through NTS-KE again, but that doesn't happen during normal operations. You need to do something like drop 8 packets in a row. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: tlsport & ntpport
> *tlsport XXX* Contact the NTS-KE server on TCP port XXX. > *ntpport YYY* Request an NTPD server on UDP port YYY. > Can anyone explain to me a case in which these are not equivalent to expcit > port prefixes on a server, ask, re require address? We've survived for a long time without being able to specify the NTP port number. It might be handy for testing. Doesn't seem worthwhile to me. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Implementing NTS options
Eric: > I'm not seeing anything in that 'graph which would ever *require* you to > disable down-version TLS. The last normative is a MAY, not a MUST. It starts with: > Implementations MUST NOT negotiate TLS versions earlier than 1.2, so we have to do something. Me: >> I assume the default would be no for TLS 1.2 and yes for TLS 1.3 >> Should we be specifying min version rather than allowing various versions? >From several messages ago: Since Gary was suspicious of 1.3, I poked a bit. 1.3 is not widely available yet. (Available enough to test.) I think we should specify a min version of 1.2 Another item for the review occasionally list. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Implementing NTS options
Eric said: > So tell me: can we conform by *discovering* the cipher set at startup time > and shipping that list to NTS-KE? Because if the RFCs don't for some insane > reason *forbid* that behavior, it's clearly the right thing. I don't know how to do that with a clean/simple API. I'm far from a wizard, but I have poked around a bit in that area and would have added it to digest-find if I had noticed anything like that. We might be able to brute force scan a few thousand slots. I think there are command line tools or man pages that list them all. We could look at the source for the command line tool - or ask on their mailing list. My straw man would be to pick a small handful of good ones and check that they are supported. That gets us off the ground. The list needs to be reviewed occasionally or we need to fix that code sometime. $ openssl ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_ AES_128_CCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:EC DHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-CCM: ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-CC M:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDH E-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384: AES256-CCM:AES128-GCM-SHA256:AES128-CCM:AES256-SHA256:AES128-SHA256:AES256-SHA: AES128-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-C CM:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-CCM:DHE-RSA-AES256-SHA256:DHE-RSA-A ES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:PSK-AES256-GCM-SHA384:PSK-CH ACHA20-POLY1305:PSK-AES256-CCM:PSK-AES128-GCM-SHA256:PSK-AES128-CCM:PSK-AES256- CBC-SHA:PSK-AES128-CBC-SHA256:PSK-AES128-CBC-SHA:DHE-PSK-AES256-GCM-SHA384:DHE- PSK-CHACHA20-POLY1305:DHE-PSK-AES256-CCM:DHE-PSK-AES128-GCM-SHA256:DHE-PSK-AES1 28-CCM:DHE-PSK-AES256-CBC-SHA:DHE-PSK-AES128-CBC-SHA256:DHE-PSK-AES128-CBC-SHA: ECDHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-AES256-CBC-SHA:ECDHE-PSK-AES128-CBC-SHA25 6:ECDHE-PSK-AES128-CBC-SHA $ -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: NTS client configuration support has landed
> I think this discussion really needs to take into account that the NTS-KE > communication happens inside a TLS session, which is a layered communication > channel w/ internal state. Possible solutions can be implemented at several > of these layers. Taken at face value the current RFC would imply a full TLS > session teardown and reconnect. I think that you could do the same > "reconnect" while keeping the TLS session open (thus avoiding all the > certificate checks and cipher negotiation) and just re-key. Last but not > least I _think_ it is possible to have several virtual connections inside the > same TLS session (that would only work for NTS if they can at least have > different IV), so that would be another route to ask for multiple servers > within one TLS handshake. Good sugestions, thanks, but it's all an implementation of get a batch of answers from one NTS-KE server. I think it would be simpler to fix the NTS-KE protocol and probably a good idea to stay away from non-mainline uses of TLS. I think we should put pool stuff on the back burner. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: What's up with our MAC support?
># 1, the packet is a crypto-NAK; if 3, the packet is ># authenticated with DES; if 5, the packet is authenticated The DES stuff is news to me. NTP classic had stand alone code for MD5 and SHA1. We carried that along until we decided to require libcrypto. > I don't know how that relates to the set of MAC lengths implied by > libcrypto's support list. I didn;t find good search hits for that. If you pick an algorithm with a digest length bigger than 20 bytes, it gets truncated. I'm not sure what happens if you pick one with a digest length less than 16 bytes. attic/digest-find is your friend for things like this. I should add DES and DES3. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: NTS client configuration support has landed
>> If you ever do that, don't forget to merge in the fudge stuff. > Sorry, I didn't understand that. Your description of server/refclock/pool skipped over a wart. The grammar for setting up refclocks has a side door for more options, the fudge command. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: NTS client configuration support has landed
Eric said: > Can we toss out these cipher config options in favor of a mechanism that > *discovers* what the available cipher are and does the right thing? I believe that server ntp.example.com nts should work in many/most cases. We'll have to provide sensible defaults for all of the options. We need to setup a mechanism to review the defaults occasionally. Maybe with each release. Maybe on Mark's birthday. The idea is to track progress in the crypto community. If the default today is to allow TLS 1.2, sometime we should bump the min up to 1.3. Yes, that means breaking backwards compatibility. Lots of warning... -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntp.conf changes for NTS
> Sorry, this is plain nonsense. You will not create enough messages for this > to ever be a problem even on a terabit link. And the RFC already asks you to > do a key rollover on a ~day timescale, so you have even less chance to > produce so many messages. Different keys. The rollover covers K, the server key used to encrypt part of the contents of cookies. The per client-server pair of keys, C2S and S2C don't roll over as long as the connection works reasonably well. I asked about key lifetime on the NTP list and Daniel said we don't have to worry about it. https://mailarchive.ietf.org/arch/msg/ntp/lV74s2I97P8ncJdjsIKvlcAgEG0 > The recommendation for AES-SIV is to encrypt no more than 2**48 > messages under the same key. At one message per second that's almost 9 > million years. If you (unwisely) use AES-GCM instead, where the > recommended limit is 2**32 messages, that's still 136 years. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: NTS client configuration support has landed
Gary said: > As a practical matter, in the current world where TLS 1.3 does not really > exist, a max of 1.2 makes sense. Gonna be a long time before 1.3 works. I assume that "max" is a typo for min. 1.3 is available in the latest versions of Fedora and FreeBSD. It's not in the previous versions. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: What's up with our MAC support?
Eric said: > The docs still talk about MD5 and SHA-1, but the comments in ntpkeygen > reference something called AES-128 which doesn't seem to be referenced at all > in the docs or the NTP RFCs. AES-128 is the replacement for SHA1. If there isn't an RFC, there is a ready-to-publish draft. It's mentioned in NEWS for 1.1.2 which says: Support AES-128-CMAC for authentication https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ I "fixed" ntpkeygen to generate AES-128 keys rather than the mix of MD5 and SHA1 it used to make. Apologies if I didn't fix the documentation. > Have we broken compatibility with other NTPv4 implementations using MD5 and > SHA-1 MACs? No. The actual code will use any algorithm your libcrypto supports. Your distro may drop support for old crufty algorithms, but MD5 and SHA1 are so widely used that I'd be surprised if anybody drops them. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Implementing NTS options
>>*tls1.2* Allow TLS1.2 connection. >>*tls1.3* Allow TLS1.3 connection. > Second, why would you ever want one of these allow bits off? I want to hear > a good story here not just to convince me that they're worth the complexity > but so it can go in the documentation. >From the draft: Implementations MUST NOT negotiate TLS versions earlier than 1.2, SHOULD negotiate TLS 1.3 [RFC8446] or later when possible, and MAY refuse to negotiate any TLS version which has been superseded by a later supported version. I assume the default would be no for TLS 1.2 and yes for TLS 1.3 Should we be specifying min version rather than allowing various versions? Do we need a way to test 1.2? Maybe we can wait until we find a box that doesn't support 1.3 yet. -- > Again. The barrier to entry for these is higher because they would need a > non-trivial grammar modification Does the grammar support quoted strings? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: NTS client configuration support has landed
> The only way to avoid this would be for me to go out of my way to create > distinct grammar branches for *each declaration type*. If you ever do that, don't forget to merge in the fudge stuff. [Specifying nonsense options, like refid for a server.] > Considering that we're talking a quarter century of road miles...well, I'm > going to want to actually *see* a bug report like that before I incur the > complexity cost to prevent it. We could fix that by checking for silly options at your fancy copy-over stage. >> My gut feel is that 'nts' can not be part of >> the 'pool' as then a casual attacker can break the system. > You might be right, but I'm not going to design on the assumption that you > are because the payoff matrix is too asymmetrical. Just because the current pool is untrustworthy doesn't mean that somebody couldn't run a trusted pool. Keep in mind that pool+nts isn't well specified yet. Do we want to get the info for several servers with one NTS-KE connection, or do we want to do the a DNS lookup to get several IP Addresses and then use separate NTS-KE connections with each of those addresses? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: NTS client configuration support has landed
Gary said: >>> *tls1.3* Allow TLS1.3 connection. >> This does not feel scalable as new versions of TLS get created. > Yeah. You prolly guessed I stole of lot of the options from elsewhere. This > one also bugged me. The API for SSL has way to set the min protocol version. SSL_CTX_set_min_proto_version(ctx, TLS1_3_VERSION); >> Please call this "ciphersuites" to match OpenSSL and other >> applications. > I can not find that in the OpenSSL doc: I've seen it. I'm not sure where. Maybe in a whats-new with 1.3 section. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: NTS client configuration support has landed
Eric said: > I have added a note about MD-5 and SHA-1 being rather broken at this point, > and a warning that MAC authentication may be removed in a future release. What's wrong with MAC authentication when used with a good algorithm? Is the security any worse than NTS? I think we should support it, loud and clear. It's a good backup in case anybody finds problems with TLS or an admin doesn't want the clutter of a NTS-KE server and certificates. Actually, we should move it to an extension so we can phase out the old mode. I'd be happy to reject MD5 and SHA1. The current code supports any algorithm that libcrypto supports. attic/digest-find will list a bunch of them. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Do certificates for IP Addresses work?
If I start with a name, translate that to an IP Address, make a TLS connection to that system, I expect to get a certificate that matches the name. But that translation step adds another layer of security considerations. Is it practical to bypass the DNS lookup and use a certificate for the IP Address? Is there an option I can give to something like getaddrinfo() that says require DNSSEC? What fraction of the world is using DNSSEC and/or pays attention if somebody else uses it? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: NTS client configuration support has landed
Gary said: > *ask [address]... > *require [address]... ... > More to come, but I'd rather not get too far ahead, as what I had thought was > consensus has disappeared. Thanks. Those are all interesting, but I was more interested in the nts foo vs server foo nts part of the discussion. Which one is preferable and why? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: NTS client configuration support has landed
Gary said: > No. There are at least 5 new options for the nts. > Worse, some of the options mean different things for server and nts. Would you please write up a summary in a new thread. There has been a lot of discussion in this area and I haven't seen anything that makes it obvious that there is anything better than "server foo nts". -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntp.conf changes for NTS
Gary said: > But then how do I say I want 2 from this pool and 2 from that pool? With the current code, you can't. I don't think we should tangle that discussion with NTS. >> If you need more, it does another DNS lookup. > And, of course, that DNS thing is problematic with NTS... I think there is a reasonable parallel between get another server via DNS and get another server via NTS-KE. There are (at least) two ways to interpret: pool pool.example.com nts 1) It could do a NTS-KE connection to pool.example.com and get back several IP Addresses and associated cookies. The protocol doesn't support that yet, but seems reasonable to extend. 2) It could do a DNS lookup on pool.example.com, get back several IP addresses, then do a NTS-KE dance with each address. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntp.conf changes for NTS
Gary said: > Maybe expanded to ask for 3 pool servers: > nts nts-ke.example.com pool 3 The current pool code doesn't work that way. Maybe it should, but it doesn't. There is no way to specify how many servers you get. There is a global variable specifying how many servers to get, Individual servers via "server" count. If you have more than one pool statement they both/all contribute. If a pool server stops responding, it is discarded. If you need more, it does another DNS lookup. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Python module mismatch
Gary said: > To refresh your memory, the python module version checks are new. > That broke casual multiple python side-by-side installs. It also exposed a potential bug. If you change the API to a module and forget to install the other version you can get confusion. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: NTP - big picture
Gary said: > Not really. If you have a fixed public hostname, then Lets Encrypt is easy > and quick. If you do not have a fixed public hostname, then game over. Let's encrypt says you need a domain rather than just a public hostname. > In order to get a certificate for your website's domain from Let's > Encrypt, you have to demonstrate control over the domain. Thanks, but I'm looking for a way to test without a domain. Lots of people have more than one box at home. They should be able to test and experiment without getting a domain. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntp.conf changes for NTS
Eric said: > If there's another revision in process, I want to object to the binary > request format. Raises endianness issues for no good reason. Better to use > something like Motorola S-records for this. I don't see how hex encoding helps anything. You still have the problem of are integers sent big-endian or little-endian. I was expecting you to suggest JSON. A lot of IETF work uses ASN1. I'm not convinced your switch-to-text is appropriate for this problem. The key idea is that the basic NTP packet is small and fixed format. Converting to text either adds another dependency with a complicated API because it's designed to handle complicated cases or we have to maintain another module to do the marshalling/unmarshalling. I'm probably biased. I've been working with byte swapping for ages. Adding extensions (which are necessary for NTS) complicates things. I'm hoping that you would come up with a clean structure. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntp.conf changes for NTS
> No, re-keyed -- you specifically want to avoid the TLS renegotiation or even > worse, reconnection. The session itself stays open. You could conceivably > just open another connection inside the same session as far as TLS is > concerned. I don't know which of the two options is more efficient. I think we would want to tweak the protocol to handle the pool case. The current pool code does a DNS lookup, for each answer, it skips ones that are already active and takes new ones. If it wants more, it tries again in a while. That will work if there is only one answer. That does depend on the server not returning the same answer every time. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: NTP - big picture
> Are there any big chunks I didn't mention? Getting libaes_siv to build on NetBSD. Eric: Please be sure this gets on your list as must-happen-before you add code that uses it. (An alternative is to add a build time option for NTS.) -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
ENABLE_MSSNTP - is anybody testing it?
Or does anybody know if that path has been tested? If so, when? In case you don't recognize the term, it's when you get with --enable-mssntp ntpd calls out to a Microsoft server to authenticate a response packet. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Byte swapping
The Internet is big endian. Intel is little endian. When I say byte swap below, I'm assuming they turn into no-ops on a big endian system. We have to byte swap integers and floats. We don't swap arrays of bytes -- text or binary blobs like cookies. On transmit, we have to do the byte swapping before the authentication/encryption. On receive, we have to do the authentication/decryption before the byte swapping. The RefID is the only ugly case I know about. If you define it as a string, we don't swap it near the wire but we have to swap IP Addresses (integers) as we store into that slot or load from it. If you define it as an integer, we swap it near the wire, you can load/store IP Addresses directly, but you have to swap text when you load/store them. Crypto gets interesting. I think what's going on is that the implementation has to understand byte swapping. If the RFC for the algorithm is described in bytes, the obvious implementation just works. If the algorithm is described in words but the API uses bytes, then the implementation has to think in byte swapped terms. For example, if the algorithm is xor data words with 0x11223344, the actual implementation would xor with byte-swap(0x11223344). - I think a cleaned up version of the above should be captured someplace -- after people check it. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
NTP - big picture
I think we should step back and look at the big picture. Eric started working on the bits but got sidetracked on some cleanups. I think we need to think hard about how/where/when we do the byte swapping. More in another message. This isn't specific to NTS, but NTS is the first time we have used extensions and they are tangled up with byte swapping. There is discussion going on about the changes to ntp.conf. The other large area I can see is TLS and certificates. We are going to need good documentation to guide a server operator through setting up certificates. (Pointers to other documentation are fine.) We are also going to need documentation for how to setup self-signed certificates for testing. I poked around a bit but didn't find what I needed before I shifted to something else. If anybody is familiar with TLS, I think it would be wonderful if we had some throw-away code that was a TLS server and client that we could use for testing certificates. Are there any big chunks I didn't mention? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Python module mismatch
Gary said: > The ntpsec ebuild for Gentoo installs multiple python modules. I wonder if > this recent change broke that? I don't remember any recent changes in the install area. The change was to add version checking. It has pointed out a real problem with separate locations for python2 and python3 imports. If you made a change in a module API, installed the python2 version but forgot to install the python3 version, you could get obscure errors. I don't know anything about Gentoo. Fedora, Debian, NetBSD, and FreeBSD all install several python modules and the corresponding binaries. I think the same list of files get installed for both python 2 and 3. The python versions are the same, the binaries may be different. We treat them as a bag of bits. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Python module mismatch
Gary said: > I installed for Python 2.7, then I installed for Python 3.6. Then I ran with > python3.6, but my PYTHONPAATH was still for 2.7. Do typical installations run mixed python 2 and 3 like that, or is that only used for testing? --- I think the mixed case can be made to work with something like: WHEN=`date +%s` puthon2 ./waf configure --build-epoch=$WHEN build install puthon3 ./waf configure --build-epoch=$WHEN build install --- Can we make waf smart enough to install both flavors? I'm thinking of something like call out to the other python to find out where to install the python libraries and make the binaries. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Python module mismatch.
Gary said: > Great, the python library mismatch code works: > Library/Binary version mismatch > Binary: ntpsec-1.1.3+ 2019-01-30T21:25:37Z (git rev ab0ea27cf) > Library: ntpsec-1.1.3+ 2019-01-30T21:20:27Z (git rev ab0ea27cf) What did you do to get that? The version strings come from waf configure. Right? So you did something more complicated than a simple edit/build/test, or edit/build/install/test. Maybe you are trying to switch between python2 and python3 when running installed code? I think that takes separate configures to make the libraries which means only one will pass the version check. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 'AnsiTerm' object has no attribute 'buffer'
>> Also, Python 3.6.7 on FreeBSD > Context? Is that a pass or a fail? Fail. Somebody was looking for a test case. It (and the previous one on NetBSD) both work from my normal script which tee-s the output to a log file. Both fail when ssh-ed to that box and run ./waf without the tee. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 'AnsiTerm' object has no attribute 'buffer'
Also, Python 3.6.7 on FreeBSD -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 'AnsiTerm' object has no attribute 'buffer'
> Btw, I tried to reproduce this failure with 3.5.6, 3.6.7, and 3.7.1, without > success. Do you have any tips for reproducing? Input/output redirection? > Environment variables? I can get it on NetBSD 8.0 with a simple ./waf configure build That's over ssh Python 3.7.0 (default, Sep 26 2018, 00:09:08) -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
leap smear broken
Would some CI wizard please add running tests/option-tester.sh on the most convenient OS/distro. Or maybe once per OS. - [64/93] Compiling ntpd/ntp_proto.c ../../ntpd/ntp_proto.c: In function ‘fast_xmit’: ../../ntpd/ntp_proto.c:2267:15: error: assignment to expression with array type xpkt.refid = convertLFPToRefID(leap_smear.offset); ^ In file included from ../../include/ntp_stdlib.h:16:0, from ../../include/ntp.h:15, from ../../include/ntpd.h:13, from ../../ntpd/ntp_proto.c:7: ../../ntpd/ntp_proto.c:2269:11: warning: passing argument 1 of ‘__bswap_32’ makes integer from pointer without a cast [-Wint-conversion] ntohl(xpkt.refid), ^ ../../include/ntp_debug.h:27:12: note: in definition of macro ‘DPRINT’ mprintf arg; \ ^~~ In file included from /usr/include/endian.h:60:0, from /usr/include/arm-linux-gnueabihf/sys/types.h:216, from /usr/include/arm-linux-gnueabihf/sys/uio.h:23, from /usr/include/arm-linux-gnueabihf/sys/socket.h:26, from /usr/include/netinet/in.h:23, from /usr/include/arpa/inet.h:22, from ../../include/ntp_fp.h:8, from ../../include/ntp.h:12, from ../../include/ntpd.h:13, from ../../ntpd/ntp_proto.c:7: /usr/include/arm-linux-gnueabihf/bits/byteswap.h:44:1: note: expected ‘unsigned int’ but argument is of type ‘unsigned char *’ __bswap_32 (unsigned int __bsx) ^~ -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 'AnsiTerm' object has no attribute 'buffer'
Gary said: >> https://secure-web.cisco.com/... > That is NOT the link I sent! Someone's email is messing with links! > Why would something called "secure-web" be doing non-secure things??? It's not uncommon for malware/spam filters to do things like that. They don't touch the links unless/until you try to open them. It gets around various problems that happen if you try to inspect links when the mail arrives. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 'AnsiTerm' object has no attribute 'buffer'
Gary said: > Update: > Works: 2.7, 3.7 > Fails: 3.5, 3.6 It was working a week or two ago. Did we change anything? (I don't think so.) Did something in Python change? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntp.conf changes for NTS
Gary said: >> How about: >>server ntp.example.com nts 1.2.3.4 >> or >>server ntp.example.com nts bob.example.com > Why do we need ntp.example.com at all? Aren't we supposed to use the NTPD > server returned from bob.example.com? The intent was to do the NTS-KE dance with ntp.example.com and use 1.2.3.4 or bob.example.com as the NTP server. -- As an aside, bob.example.com could return multiple IP Addresses. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntp.conf changes for NTS
> I'd suggest using a new keyword for that and leaving the existing ones > behijnd for NTP w/o encryption. Then we'll need 2 new keywords. We want NTS to work on pool sites too. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: First NTS code
e...@thyrsus.com said: >> Your "empty cookie string as a sentinel" doesn't work unless you allocate >> space for the extra slot. > Eh? We know what the maximum number of cookies is. I think all we have to do > is notice which cookies are empty (have initial NUL). But I might be wrong > about that; I'm not wedded to that representation, it's an inside-NTS thing > that belongs to whoever writes the cookie extraction code. Initial NUL doesn't work. Cookies are binary blobs. 0 is a valid data byte. I'm not sure what you mean by "sentinel". The array of cookies is a FIFO. If you have 2 indexes for read+write, you have to decide if equal means empty or full. If you make the array one bigger the full-equal case never happens. You have to make sure you never insert too many. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: vc Digest, Vol 41, Issue 53
> +#define NTS_COOKIELEN128 /* placeholder - see RFC 6 */ Again, that should be MAX, and we need lengths. Our client talking to another server implementation may get a different length. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
ntp.conf changes for NTS
How should we tell the system we want to use NTS when talking to a server? The catch is that we potentially need two names/addresses. I think the simple case is just: server ntp.example.com nts That will do a NTS-KE exchange with the system at ntp.example.com and use the IP Address it returns. The complicated case is when we want to specify the IP Address. How about: server ntp.example.com nts 1.2.3.4 or server ntp.example.com nts bob.example.com -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: First NTS code
Eric said: >> They are mostly binary blobs: cookies, keys, nonces, ... >> It might be worth packaging blob and length into a struct. > OK. That's inside-NTS work - do as you like there. I need to concentrate > elsewhere for a bit. How about packaging the blob of bits with a 4 byte header: 2 bytes of length and 2 bytes of tag/type/whatever? The idea is to match NTP extensions and similar. We have to byte swap the header word. I think the other stuff is a stream of bytes and doesn't get swapped. I think things like crypto code have to work in byte swapped mode when do word operations on a little endian system. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpmon oddness
Gary said: > Something odd with ntmn today. See attached. I expec this cut/paste gets > mangled in email: How recent is your git pull? Eric was working on refids recently. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Should we get a waf?
> Are there any features in waf 2.x that you were looking forward to? Or do > you just want us to avoid getting too far behind? Just trying to avoid getting too far behind. If nothing else, I'd like their online documentation to correspond to the version I'm trying to debug. - I still don't understand how libraries work and haven't found the place that explains it. I see things like this in ntpd/wscript: use="libntpd_obj ntp M parse RT CAP SECCOMP PTHREAD NTPD " Is there anything magic in the capitalization? It seems to not complain on non-Linux systems that don't have libseccomp so I'm guessing that they are ignored unless you have checked to verify that library exists. Mostly, I'm trying to understand how Eric gets -python when I don't. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: First NTS code
e...@thyrsus.com said: >> Do we want to store cookies and passwords and such in a fixed max-size array >> or as heap allocated blobs? In any case, we need to remember the lengths. > Depends - if they're textual we can assume a '\0' sentinel. I'd prefer to do > that if possible, it would minimize the amount of data items to manage and > thus potential defects. They are mostly binary blobs: cookies, keys, nonces, ... It might be worth packaging blob and length into a struct. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Pipeline failed: MacOs, strlcat
Matt: Thanks. Eric: That was an example of why we might want an option for NTS work. Did the CI pipeline work for you? Or did you overlook the failed message or were you away from email, or ... If so, how did my pthread change trigger this problem? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: First NTS code
You have a couple of trailing spaces. We should start collecting max/min/required lengths and references to where that number comes from. Do we want to store cookies and passwords and such in a fixed max-size array or as heap allocated blobs? In any case, we need to remember the lengths. There are lots of places where we will be passing around c2s and s2c. Maybe we need a struct for them (and lengths). -- You should probably add a section for global variables for the server side. I'd call them nts_K and nts_I, using the names from RFC section 6 and nts_old_K and nts_old_I Maybe the cookie stuff should be in a separate module. We'll also need the AEAD algorithms we support and their crypto pointers. #define NTS_COOKIES 8 /* RFC 4.1.6 */ I'd call that MAX_COOKIES The client side needs: c2s and s2c, and lengths array of bools for which cookies are valid and another for unused. an array of cookie lengths. the AEAD algorithim we are using. Probably 2 of them, the IETF number and the pointer to the crypto stuff. The struct info needs to move from nts.c to nts.h We need one per server, in the peer struct. Your "empty cookie string as a sentinel" doesn't work unless you allocate space for the extra slot. -- nts_client_ke_request nts_server_ke_verify Those are poor names considering what you have them doing in the comments. I would have picked nts_ke_client and nts_ke_server. Actually, what you want at this level is nts_ke_server_start. The actual per-client server processing is internal to the server. It calls out to nts_new_cookie (8 times) - The descriptions for nts_validate and nts_decorate seem fishy. I think we need separate routines for client and server. (that is 4 total) -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
What does NTS mean?
Does NTS refer to an NTP system that supports the new draft, thus leaving NTP to refer to old NTP systems that don't support it? Or does NTS refer to just the new draft and we can assume (from context) that NTP refers to either the old pre-draft systems or the new post-draft systems that do include NTS support? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Pipeline failed: MacOs, strlcat
https://gitlab.com/NTPsec/ntpsec/-/jobs/151892721 Can somebody give me some help with this. This is after my pthread cleanup, but I don't think I changed that area which probably means that I'm missing something interesting. [54/87] Compiling ntpd/ntp_io.c In file included from ../../ntpd/nts.c:15: In file included from ../../include/ntp.h:15: ../../include/ntp_stdlib.h:142:15: error: expected parameter declarator extern size_t strlcpy(char *dst, const char *src, size_t siz); ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/ SDKs/MacOSX10.14.sdk/usr/include/secure/_string.h:108:47: note: expanded from macro 'strlcpy' __builtin___strlcpy_chk (dest, __VA_ARGS__, __darwin_obsz (dest)) ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/ SDKs/MacOSX10.14.sdk/usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz' #define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0) ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/ SDKs/MacOSX10.14.sdk/usr/include/secure/_common.h:30:32: note: expanded from macro '_USE_FORTIFY_LEVEL' #define _USE_FORTIFY_LEVEL 2 ^ ... -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Should we get a waf?
It's up to version 2.0.14, Dev 2018, about a year since the version we are using. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
libraries, pthread cleanup, remove libthr support
I'd like to get rid of wafhelpers/check_pthread.py There may have been some PTHREAD conditionals in our code ages ago, but they are all gone. The main thing check_pthread is doing is setting up to use libthr rather than libpthread. FreeBSD uses libthr.so rather than libpthread.so. But it has links, so asking for -libpthread works but ldd will show libthr.so lrwxr-xr-x 1 root wheel 10 Dec 6 20:12 /usr/lib/libpthread_p.a -> libthr_p.a lrwxr-xr-x 1 root wheel 9 Dec 6 20:12 /usr/lib/libpthread.so -> libthr.so lrwxr-xr-x 1 root wheel 8 Dec 6 20:12 /usr/lib/libpthread.a -> libthr.a So FreeBSD works without anything special. The other interesting case that I can test locally is musl on Alpine Linux. It doesn't have libpthred.so, but does have -rw-r--r--1 root root 8 Jun 19 2018 /usr/lib/libpthread.a alp:~$ cat /usr/lib/libpthread.a ! alp:~$ I assume that is a flag for some magic, but I haven't tracked it down. Linking with -lpthread seems to get folded into musl: alp:~$ ldd /usr/local/sbin/ntpd /lib/ld-musl-x86_64.so.1 (0x7957db6bc000) libcrypto.so.1.0.0 => /lib/libcrypto.so.1.0.0 (0x7957db051000) libcap.so.2 => /usr/lib/libcap.so.2 (0x7957dae4c000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7957dac3a000) libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7957db6bc000) libz.so.1 => /lib/libz.so.1 (0x7957daa23000) alp:~$ In hindsight, it seems reasonable to expect -lpthread and friends (eg -lm and -lrt) to work, one way or the other. Not having that would be a huge pain in the ass when porting code. Their man pages are normal Linux pages. Any reason not to push this? Why is -lrt optional? ctx.check_cc(lib="rt", mandatory=False, comment="realtime library") We need it for timers: timer_create, timer_settime, and timer_gettime. Do POSIX specs include the library? Even if the actual code is in libc, I'd expect most system would have a dummy librt just to help portability. - What's the advantage of checking for a library via pkg-config? waf ctx.check_cfg vs ctx.check_cc? We use it for libcrypto and libseccomp, with a fallback to the simple version. This doesn't solve the -pthread vs -lpthread tangle. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Are we going to have a no-NTS-KE build option?
e...@thyrsus.com said: > I do. But I'm not worried that introducing NTS code will destablized non-NTS > code, either. It wouldn't surprise me if we used a routine that wasn't in older versions of libssl. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Are we going to have a no-NTS-KE build option?
Eric said:
> What would a build option gain us? Is there some specific prerequisite
> you're worried about?
It seemed like good insurance. If we want to fix a bug, you seem to prefer to
release the current git head rather than making a branch.
There is a specific example. Daniel's libaes_siv doesn't build on NetBSD.
/home/murray/ntpsec/libaes_siv/aes_siv.c:114:24: error: expected declaration
specifiers or '...' before '__builtin_constant_p'
static inline uint64_t bswap64(uint64_t x) { return __builtin_bswap64(x); }
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: Are we going to have a no-NTS-KE build option?
To answer the question in the subject... I think we will want it in the short term in order to keep builds working on all current platforms until we get things sorted out. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Various cleanups: threads, STA_NANO
> I think we covered this in https://gitlab.com/NTPsec/ntpsec/issues/421 I think that's a different issue. OpenBSD doesn't support that API at all. The STA_NANO case I'm interested in is several ifdef-s in ntp_loopcontrol No big deal, just some clutter we might be able to remove. The question is: Do any of the systems we want to support have an old version of ntp_adjtime, old enough that it doesn't know about STA_NANO. If so, I'd like to collect a list. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 'AnsiTerm' object has no attribute 'buffer'
Gary said: > That one failure is on Gentoo stable. Oddly I have many other Gentoo stable > that do not show the same problm. That's consistent with what I'm seeing. > I'm guessing it is more an environment setting than distro dependent. Could be, but I can't think of anything I've changed in that area recently. I think there was an update to ssh. ??? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: lockclock runtime option
e...@thyrsus.com said: >> Perhaps we should review this area. What will we want to see >> when NTS is deployed. > You and Achim are probably the best judges of that we have. So write a > strawman and put it in nts.adoc. I don't plan to put anything related to this into nts.adoc ntp_control is a mess, and I don't want that to get tangled up with NTS -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: lockclock runtime option
> So, lockclock is not known as a system variable of course. I just pushed a fix for that. $ ntpq ntpq> rv 0 lockclock lockclock=0 ntpq> ntp_control really needs a big cleanup. There are several tables that must be kept in sync by hand. I added issue #539 for that. (It may be a duplicate, but I didn't see an old one.) -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 'AnsiTerm' object has no attribute 'buffer'
Gary said: > I'm getting an odd build error on one of my hosts. Ideas? I asked about the same quirk yesterday evening. No responses. What OS/Distro are you using? I've seen it on NetBSD and FreeBSD. I thought I had one on Linux, but didn't have an example handy when I typed things in. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Are we going to have a no-NTS-KE build option?
> James, you are correct. Privileged ntpq functions require the crypto. Not quite. Privileged operations require a password, but it is sent in the clear. There is no crypto on that path. The packet format doesn't support it. We could fix that at the cost of breaking compatibility. The crypto is used for making cookies. They are used to prevent DDoS amplification. > Hal, I don't see requiring libcrypto/lssl as a problem. At this point I'm > more interested in reducing our range of build variants than I am in snipping > off dependencies towards a (rather theoretical) crypto-less build. Should I remove --disable-dns-lookup? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: lockclock runtime option
Achim said: > Well, it turns out ntpq has regressed from classic and doesn't understand at > least some of that syntax anymore: > NTPsec~> ntpq -c 'rv 0 offset' > server=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync, > version="ntpd ntpsec-1.1.3+ 2019-01-21T16:51:20Z (git rev 6c029ef4c)", ... Works for me. Anything interesting about your setup? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Are we going to have a no-NTS-KE build option?
I'm thinking of updating INSTALL and/or devel/hacking.adoc to say something about pthreads and OpenSSL. If we did away with shared key authentication, we could potentially do away with needing libcrypto. Aside from authentication, we also use RAND_bytes() so we would need to substitute something for that. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Various cleanups: threads, STA_NANO
e...@thyrsus.com said: > In particular, some of our targets (some BSDs, I don't remember which) have > only microsecond, not nanosecond resolution in the clock-adjustment calls. NetBSD and FreeBSD have NANO. Matthew Selsky suggested Solaris. Can anybody confirm that? Anybody know of others? > No, actually, we *don't* need to make that effort. I've already solved this > problem. Yes. But there are enough NANO ifdefs left in ntp_loopfilter to attract my attention. The combination of new enough to have clock_gettime yet old enough to have ntp_adjtime without STA_NANO seems unlikely. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Various cleanups: threads, STA_NANO
> The C code has no #ifdefs for HAVE_PTHREAD or HAVE_PTHREAD_H, so we're only > talking about cleaning up some waf python code, correct? Yes, or eliminating it. Simplifying "little" things like this often allows simplification in some other area. > libthr is a FreeBSD thing... Thanks. On a FreeBSD system, I just commented out these two lines: #ctx.check_cc(lib="thr", mandatory=False, # comment="thr library, required by some operating systems.") And it still builds and ends up using libthr. The man page says: POSIX Threads Library (libpthread, -lpthread) I assume there is magic in there to translate -lpthhead to -lthr, but maybe it's just getting it from libcrypto. But this is all tangled up with -pthread vs -lpthread and that discussion suggests out of date documentation, so who knows what is going on. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
AttributeError: 'AnsiTerm' object has no attribute 'buffer'
Anybody recognize this? I've seen it on NetBSD and FreeBSD I haven't figure out what I'm doing to make it happen. Waf: Leaving directory `/home/murray/ntpsec/foo/build/main' Traceback (most recent call last): File "/home/murray/ntpsec/foo/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/w aflib/Scripting.py", line 122, in waf_entry_point run_commands() File "/home/murray/ntpsec/foo/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/w aflib/Scripting.py", line 183, in run_commands ctx=run_command(cmd_name) File "/home/murray/ntpsec/foo/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/w aflib/Scripting.py", line 174, in run_command ctx.execute() File "/home/murray/ntpsec/foo/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/w aflib/Scripting.py", line 377, in execute return execute_method(self) File "/home/murray/ntpsec/foo/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/w aflib/Context.py", line 88, in execute self.recurse([os.path.dirname(g_module.root_path)]) File "/home/murray/ntpsec/foo/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/w aflib/Context.py", line 129, in recurse user_function(self) File "/home/murray/ntpsec/foo/wscript", line 931, in init_handler obj.execute() File "/home/murray/ntpsec/foo/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/w aflib/Scripting.py", line 377, in execute return execute_method(self) File "/home/murray/ntpsec/foo/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/w aflib/Build.py", line 104, in execute self.execute_build() File "/home/murray/ntpsec/foo/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/w aflib/Build.py", line 123, in execute_build self.post_build() File "/home/murray/ntpsec/foo/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/w aflib/Build.py", line 280, in post_build m(self) File "/home/murray/ntpsec/foo/wscript", line 888, in bin_test from wafhelpers.bin_test import cmd_bin_test File "/home/murray/ntpsec/foo/wafhelpers/bin_test.py", line 10, in import ntp.poly File "/home/murray/ntpsec/foo/build/main/tests/pylib/ntp/poly.py", line 111, in sys.stderr = make_std_wrapper(sys.stderr) File "/home/murray/ntpsec/foo/build/main/tests/pylib/ntp/poly.py", line 102, in make_std_wrapper return io.TextIOWrapper(stream.buffer, encoding="utf-8", AttributeError: 'AnsiTerm' object has no attribute 'buffer' -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Various cleanups: threads, STA_NANO
We have various cruft associated with threads. Can we add POSIX threads to our list of requirements? Or is it already included in POSIX.1-2001 and ISO/IEC 9899:1999 (C99)? The idea is to remove HAVE_PTHREAD_H and HAVE_PTHREAD from config.h and remove most of wafhelpers/check_pthread.py wafhelpers/check_pthread.py says: ctx.check_cc(lib="thr", mandatory=False, comment="thr library, required by some operating systems.") Is that (still?) correct? If so, which systems? There is probably cruft in this area that I added to try to avoid libpthread for the no-DNS case. That doesn't work now since libcrypto needs pthread_once and is less likely to work as we get NTS-KE working. -- We have various ifdefs for STA_NANO. We depend on clock_gettime which uses timespec so all the systems we run on know about nanoseconds. Can we upgrade our requirement for ntp_adjtime to be requires ntp_adjtime with STA_NANO? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: lockclock runtime option
Eric said: > It's never been an an *ntpq* "system variable" that can be queried through > that interface, I meant. It's easy to add new variables. Old ntpq may not show them in any of its packaged printout like peers or kerninfo, but you can get them by asking explicityly. There are also 2 ways to see a batch of variables. ntpq can ask for each variable it wants to see, or ntpd can return a batch that it thinks are interesting. --- Perhaps we should review this area. What will we want to see when NTS is deployed. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: lockclock runtime option
> Alas, it's not a system variable. Looks like it is: include/ntpd.h:extern bool lockclock; /* lock to the system clock? */ -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpq change in behaviour
> Before I forget: I really don't care about when I've configured the project. > Can that date please be the date of the corresponding commit (if it's there > at all) and the version string something that git describe puts out, like > NTPsec_1_1_3-35-g6c029ef4c (which is way more helpful to me in figuring out > which code I run at which server). ALso, please find a way to update the > version string without requiring to re-configure the whole tree. I think there are 2 cases for the version string I'd like. If I have made local edits, I want the build date. That's the best summary of the edits I've made. If I have a clean clone I want the git tag. If I have a tarball, I want whatever the tarball provides. If you hang out with geeks in this area, they want to know everything: the version of the compiler, the compiler flags, ... the OS the compiler is running on... as well as the parameters to configure. That ends up with the version string being a tag for a slot in a database. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpq change in behaviour
ntpq gets pll offset via ntp_control using CS_K_OFFSET which gets it from ntx.offset ntx comes from ntp_adjtime which is only updated if a big conditional which is all local and looks good. But check for MODE6 errors in the log file. There is nothing lockclock in that local area. So my guess is that the normal path isn't putting the right stuff into the kernel. We are missing a call to ntp_adjtime --- What's going on here is that ntpq -c kernel is reading a bunch of stuff from the kernel. Normally, it gets put there via ntpd but in the LOCKCLOCK case, it gets put there via whatever other program is disciplining the clock. The background for that is the mode where a PLL in the kernel tracks a PPS. It's not available on most kernels so we don't talk about it much. ntpd sets a bit which basically hands off timekeeping to the kernel - similar to LOCKCLOCK. A likely candidate is a call to loop_config() This looks fishy to me: * ENABLE_LOCKCLOCK: The LOOP_DRIFTINIT and LOOP_DRIFTCOMP cases are no-ops. case LOOP_DRIFTINIT: #ifndef ENABLE_LOCKCLOCK if (clock_ctl.mode_ntpdate) break; case LOOP_DRIFTINIT: if (!lockclock || clock_ctl.mode_ntpdate) break; I just pushed a fix - removing the !. Untested so far. I'm about to start serious testing. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpq change in behaviour
Eric said: > Therefore...would you please take a hard look at the change and see if you > can repair it? I hate to slough off my mistakes on anybody, but the fix > needs to be applied by somebody who can test it. Alternatively, this is a good opportunity for you to learn more about how ntpd works. Maybe Achim can give you the recipe and you can reproduce a test case and graph some of the statistics and see the difference. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: devel/nts.adoc edits
Looks good on a modern browser. The diagram doesn't render on a very old browser which can show the stand-alone diagram. Is there something tricky about the include-it recipe? I think we should keep the plain text version around for a while. How complicated is the conversion process? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
More work on devel/nts.adoc
I moved the comments about configuration away from the packet processing area to a new block on configuration. There are probably rough edges. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Key lifetime: C2S and S2C
> So enforcing key rollover isn't a concern. The recommended server key > rotation is primarily about forward secrecy then, I presume. Draft says: Erasing old keys provides for forward secrecy, limiting the scope of what old information can be stolen if a master key is somehow compromised. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: The key-manahement argument
> My thought about how to enable NTS for the pool would involve requiring a SRV > record lookup for NTS-KE That SRV lookup could return multiple names. Each would point to a separate NTS-KE server. An alternative approach would be to extend the NTS-KE protocol to support multiple answers. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: The key-manahement argument
> Imagine a server that uses the suggested cookie approach and simply never > rolls over K. As long as the client daemon is running, its cookies will be > valid and keep getting renewed. C2S and S2C will never get rolled over. > Should the client track an expiration limit in memory, and when that limit is > hit, re-run NTS-KE? Note that the client keeps using the same C2S and S2C even if the server does roll over K. --- > But there is a middle ground: opportunistic NTS. The downside of opportunistic X is that it appears to be working but may stop working without any warning. I think we should avoid it. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: The key-manahement argument
> The NTS-KE servers would have to share NTS master keys (and cookie formats!) > with volunteer NTP servers. If you are interested in security, sharing a master key with many servers seems like a bad idea - too many opportunities for a leak. With something like the pool where anybody can join (and thus get the key), security is no longer possible. There are actually two parts to TLS security. One is the technical side. Can the crypto be broken? Has the secret key leaked? The other is trust. Do you trust the name you are using? The name you used could be a malicious clone of a legitimate name: F00 vs FOO. Or the correct company could be untrustworthy. The pool might be a good way to test NTS code. I don't see how to get a serious level of trust with volunteer effort. --- We can avoid sharing the master key with many NTP servers if the NTS-KE server contacts the selected NTP server to get the initial cookies. That requires secrecy on that connection. That could be TLS and hence another certificate or a shared key. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: The key-manahement argument
Richard Laager said: > * Is NTPsec going to use the suggested cookie format? Sure, but it isn't a detailed spec. >* Is NTPsec going to force C2S/S2C key rollover (e.g. by adding an > expiration time to its cookie format) or leave expiration to clients? Maybe, but not initially. We need a crypto geek to tell us how much we can safely encrypt and/or authenticate so we can translate that back to packets. > * How is NTPsec going to handle key expiration when it is the client? I assume you are talking about K, the server master key. The normal case is easy. The client doesn't have to do anything because the server supports both the current K and the previous 1 (or 2?). For something like a laptop that goes to sleep for a week, the server will send a KoD and the client will rekey via NTS-KE. > * What configuration options will be provided for each piece? The server needs a file name for the master keys and maybe a flag to start the NTS-KE server. The client needs a new option on the server line. > * Is NTPsec going to initiate NTS by default? Probably not. That would break backward compatibility. > I've taken a stab at a bunch of edits: Thanks. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: The key-manahement argument
Eric said: > I alsop haven't seen anything yet that that relieves my worries about our > draft-conformant NTS failing to interop with someone else's draft-conformant > BTS due to varting cooke formats. Not a problem. The cookie format is private. Neither client box needs to know anything about the contents. One corner case is the initial cookies. There are 2 options. Case 1: NTS-KE server generates the initial cookies. In this case, it would need to know the NTP server's master key and the recipe for making cookies. Case 2: When the NTS-KE server wants new cookies, it asks the NTP server. In this mode, the NTS-KE server doesn't know anything about the structure of cookies or the master key. The downside is extra network traffic. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
