Hal Murray :
>
> Eric said:
> > You yourself advocated that Mode 6 ought to be replaced by an HTTP service
> > on
> > TCP port 123. I think that's a good idea, if we can do it. The problem is
> > than NTS-KE *also* wants to have TCP 123.
>
> I don't want the UI side of HTTP in ntpd.
I'd like
Daniel Franke :
> I'll post a rebuttal sometime later this week. As for IETF processes,
> though, you're years late. The WG already had a consensus call in 2016
> on what NTS-KE's framing format should look like, and it was
> unanimous. You can still comment during IETF Last Call and try to
>
Hal Murray :
>
> e...@thyrsus.com said:
> >> Do you have an example of where we need to change a
> >> driver variable on the fly?
>
> > No, I'm bothered because I'm (a) not sure we'll never need to do it, and (b)
> > pretty sure what the Dread God Finagle will arrange if I assume we won't.
> >
This is why my design sketch for NTPv5 is a JSON profile, and wgy I
intend to file an objection to the KE protocol in the NTS draft.
http://esr.ibiblio.org/?p=8254
--
http://www.catb.org/~esr/;>Eric S. Raymond
I cannot undertake to lay my finger on that article of the
Hal Murray :
> Do you have an example of where we need to change a driver variable on the
> fly?
No, I'm bothered because I'm (a) not sure we'll never need to do it, and (b)
pretty sure what the Dread God Finagle will arrange if I assume we won't. :-)
> >> We need to be able to run gpsmon while
Daniel Franke :
> Scheduler timeslices haven't changed much. The current default on
> Linux is 1ms and it's been that way for a long time. What's changed is
> that everybody has multicore processors now, so contention almost
> never happens.
Your historical baseline isn't long enough. The NTP
Hal Murray :
>
> Eric said:
> >> I don't understand. All I was trying to say is that splitting
> >> out the refclock drivers to another process shouldn't make
> >> any difference that is easily visible.
>
> > Maybe. The devil is in the details.
> > I expect some issues around Mode 6. We'd
Hal Murray :
> I think I'll take a break from NTS and go add a log file for this sort of
> thing. I want a place for the time spent in auth code.
Good idea.
--
http://www.catb.org/~esr/;>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute:
Hal Murray via devel :
> Eric said:
> > Trying to change that by breaking out a separate NTS-KE server would
> > introduce a lot of complexity when we could achieve the same result by
> > pointing the ntpd instances at a common key on a fileshare.
>
> That adds the fileshare to the security
Hal Murray :
>
> I will be seriously disappointed if you drop that code.
>
> You need it to verify that you don't need it.
Interesting point. How do you account for the fact that nobody noticed
when it was accidentally disabled for six months, though? Definitely the
kind of thing I'd expect
Hal Murray :
>
> e...@thyrsus.com said:
> >> My strawman for REFCLOCKD is something like the touring test.
> >> You can't tell the difference by poking around with ntpq. (Maybe
> >> you don't get to poke too deep.)
>
> > It'd need its own UDP port.
>
> I don't understand. All I was trying to
Hal Murray :
>
> My strawman for REFCLOCKD is something like the touring test. You can't tell
> the difference by poking around with ntpq. (Maybe you don't get to poke too
> deep.)
It'd need its own UDP port.
> There are two parts to the refclock code.
>
> The first operates on the second
Hal Murray :
>
> Eric said:
> > I meant to mention that there are actually *two* big benefits in prospect
> > from a Go port. The obvious one is being able to junk a lot of fiddly,
> > error-prone C memory-management stuff.
>
> I'm actually surprised that you haven't simplified a lot of that
Daniel Franke via devel :
> One thing ntpd does do (both in NTP Classic and in NTPsec) is fetch
> kernel timestamps on incoming packets using the SO_TIMESTAMP option.
> This is different from hardware timestamps; they're not generated by
> the NIC, they're generated by the kernel at the moment the
Ian Bruene via devel :
> On 3/2/19 9:42 AM, Eric S. Raymond via devel wrote:
> > REFCLOCKD benefits way down, cost almost unchanged. Every time I model
> > this in my head the same answer comes out: bad idea. I think we have
> > better complexity-reduction attacks availa
Kurt Roeckx :
> If this is something you're worried about, this can be solved with
> the interleave mode, which was removed.
The interleave move was removed because it was broken. There was a small but
fatal error in the packet construction. I don't remember the details, but
Damiel Franke did
Hal Murray :
> > Let me take a different tack: can we move the aut computation off path?
>
> Nope. The auth includes the whole packet. Can't do the auth until you know
> the time that you are going to put in the packet.
I was expecting that answer, but the question hd to be asked.
> We can
Hal Murray :
>
> e...@thyrsus.com said:
> >> My big concern is that nobody else seems to be testing it. There may be
> >> dragons that I haven't poked.
> > Understood. Unfortunately I myself can't be much help here - my outside
> > view
> > of NTP is still weak, I have only limited ability to
Gary E. Miller via devel :
> > > The way Mark explained it to me, you want one NTS-KE per aisle, or
> > > per rack. That limits the number of servers, with keys, that need
> > > to be protected.
> >
> > I now think this plan is a mistake and that Hal did the right thing by
> > building key
I wrote:
>Though its internal complexity remains high, ntpd is really quite small
>now. A binary with all refclocks in is 1.4GB. Which might sound like
>a lot, but vi is 2.7GB, Emacs is 16GB, and those are both skinny compared
>to more modern programs with heavy GUIs.
Jason Azze correctly
Hal Murray :
>
> Eric said:
> >> I've been collecting major items in devel/TODO-NTS
> > Is there some reason this isn't just a section in nts.adoc? (Which may need
> > some GC at this point.) The whole idea of that document was to be a planning
> > whiteboard.
>
> Only signal to noise. I was
Gary E. Miller via devel :
> The way Mark explained it to me, you want one NTS-KE per aisle, or
> per rack. That limits the number of servers, with keys, that need
> to be protected.
I now think this plan is a mistake and that Hal did the right thing by
building key service into ntpd itself.
Hal Murray :
> > I'll take responsibility for the documentation.
>
> Thanks.
>
> Be sure to include a section that says that NTS doesn't guarantee good time,
> just that you are talking to the system you expect to talk to. (modulo typos
> and such)
That's true of all three forms of
This is redirected from a bug thread on issue #563.
Hal Murray :
>
> Eric said:
> > Sadly, I think the great refclock cleanup is mostly done. There are issues
> > about the GPSD and SHM drivers but the days when I could dike out an
> > obsolete
> > driver a week are gone - we seem to be down
Hal Murray :
>
> > What still needs to be done to fully land this feature? Key rotation?
> > Anything else?
>
> I've been collecting major items in devel/TODO-NTS
Is there some reason this isn't just a section in nts.adoc? (Which
may need some GC at this point.) The whole idea of that document
Hal Murray :
> [0 not showing up in ntpq -p t column for NTS clients.]
>
> Eric said:
> > I'd fix this, but I'm not sure whether you're talking server or client side.
>
> The problem is in ntpq. Somebody returns 0 for slots that don't exist. The
> check for >= 0 needs to do a preliminary
Hal Murray :
>
> Eric said:
> > Good. I'm in favor of anything it can do to export more meaningful status
> > information, and this definitely qualifies.
>
> I assume that includes putting a digit in the t column to show the number of
> cookies and hence indicate that a slot is using NTS.
Following Hal Murray's interop report, I've updated the documentation
so that it describes NTS as implemented in conformance with the
Version draft RFC.
What still needs to be done to fully land this feature? Key rotation?
Anything else?
--
http://www.catb.org/~esr/;>Eric S.
Hal Murray :
> Eric said:
> > So this means ntpd is shipping these strings in the refid field?
> Yes
Good. I'm in favor of anything it can do to export more meaningful status
information, and this definitely qualifies.
> > I want to document this. Not sure where it goes.
>
> For things like
Hal Murray via devel :
> It now talks to Martin Langer's server.
>
> I added another hack to ntpq. (The hack is actually in ntpd, but you see in
> in ntpq -p) Where it used to show INIT in the refid column to indicate that
> it hasn't received any packets yet, it will now show NTS or DNS if
Hal Murray :
> It's a lot better. I haven't seen digits replacing the u.
>
> The hostname isn't getting printed out in a few cases:
I can't reproduce this. After last night's fix everything looks normal here,
including just after restart.
If found the bug that was producing garbage ntscookies
Hal Murray :
>
> The t column is a "u" for user/client. (Looks like "l" for refclocks. It
> used to be interesting for broadcast and such, but I think you can figure
> that
> out from the remote address.)
>
> We can put 0-8 in that slot to indicate that we are talking to that server
> with
Hal Murray :
> > Excellent. What's the bext thing you need from me?
>
> Testing. Get it up and running in your local environment. If you have a
> real
> certificate and are willing to support some testing traffic, tell me/us the
> host name and/or send us the root certificate.
If I have a
Hal Murray via devel :
>
> The server side needs a cookie and private key.
>
> The K and I used to encrypt cookies is a hack constant so old cookies work
> over server reboots.
>
> The client side defaults to using the system root certificates. You can
> provide your own.
>
> With the NTS
Hal Murray via devel :
> Here is the main thread:
> (gdb) thread 1
> [Switching to thread 1 (Thread 0x7784f740 (LWP 24041))]
> #0 0x77a41ef7 in __nptl_setxid () from /lib64/libpthread.so.0
> (gdb) bt
> #0 0x77a41ef7 in __nptl_setxid () from /lib64/libpthread.so.0
> #1
Hal, I'm thinking next I'll add a section to the Hacking Guide on how
to add new Mode 6 variables. It will be easier now.
Then you can decide whether it will be faster to do them yourself or
hand off a spec to me. I'm happy to oblige if you choose the latter.
--
James Browning via devel :
> I have a branch 'control-denum' which takes a significantly wrong
> approach and replaces many of the #define directives and replaces
> them with a trio of enums. completely untested of course. IMO a
> slightly less wrong solution might be to extend the table to have
>
Hal Murray :
> The thing that gripes me about ntp_control is that for each of the tables
> mentioned above, there are actually 3 parallel tables and they are a long way
> apart so a pain to update. Maybe if we just interlaces the #defines with the
> text lookup tables it would be less painful
Hal Murray :
> > I'll study authinfo and get back to you, probably tomorrow.
>
> authinfo is a bad example. ntpq has its own copy of that list.
ntpq has its own copy of the lists for almost *all* the standard ntpq displays.
There are only three exceptions; those lists are in ntp_control.c
> I
Hal, I've so far created three: ntskeyfetches, ntsvalidations,
ntsdecorations. They're listed by a new "ntsinfo" command in ntpq.
You should see ntskeyfetches move when a request for NTS keys has gone
through. The other two are bumped in presently-unused stubs.
I'll try to make analogs of the
Richard Laager via devel :
> Is there a particular reason this needs to be handled right now?
No. But I had some deasd time wile waur=ing for CI to unjam.
> For what it's worth, I think this should wait until NTS is done. NTPv5
> is going to require IETF action. Both the NTPsec developers and
Hal Murray via devel :
> Eric: If you feel like hacking, the thing that I'm going to want real soon
> is
> something similar to ntpq's authinfo. I think the ntpq side just displays
> whatever it gets back. That makes it easy to add more slots - server only,
> no
> changes to ntpq. If you
Whle awaiting Daniel's libaes_siv release and the unjamming of our CI,
I did some serious design work on the NTPv5 proposal at
devel/ntpv5.adoc.
It's no longer a disconnected grab-bag of wishlist items. I've
brought it to a state that is, in principle, implementable. Though the
change in
Hal Murray :
> > Let us know what work - it should be documented.
>
> This is what I used on Linux:
>
> echo "/usr/local/lib/" > /etc/ld.so.conf.d/libaes_siv.conf
> ldconfig
>
>
> This is what I used on NetBSD and FreeBSD. There is probably a
> better/cleaner
> way, but I wasn't in the mood
Hal Murray via devel :
> It worked a few days ago. It works if I comment out the pair of new lines in
> two files.
>
>
> [ 11%] Building C object CMakeFiles/runtests.dir/aes_siv_test.c.o
> In file included from /home/murray/ntpsec/libaes_siv/aes_siv_test.c:3:
> In file included from
Hal Murray via devel :
> The symptom is that it links but doesn't run. At runtime, it can't find
> libaes_siv
>
> It was installed in /usr/local/lib/
>
> It works after I add links from /usr/lib64/ over to /usr/local/lib/
I suppose a more graceful solution would be to beat waf into looking at
Jason Azze via devel :
> I predict that ESR will ask me for an alternative approach. He won't
> like my recommendation. It's to use a feature or development branch
> for a change as big as the introduction of NTS.
Even if I liked using feature branches (and I don't; see
Daniel Franke :
> Release tags match v.., so just check the tag list for
> the most recent v1.y.z. Don't automatically go to 2.anything since releases
> are semantically versioned and that would indicate backward-incompatibility.
That's going to be a pain to implement and debug in the CI context.
Daniel Franke :
> You probably don't want to auto-pull the latest HEAD every time it gets an
> update; only releases get the full battery of QA. Note I'll probably be
> stamping a release this weekend since the last release from two years ago
> has a build issue with more recent OpenSSL versions.
Hal Murray :
> Did you fix the CI checks?
>
> Is anybody working on fixing libeas_siv to build on NetBSD? Until that is
> fixed, we won't build on NetBSD.
Yikes! I forgot about the CI - I almost never have to modify it.
Matt Selsky maintains that YAML file. I've pinged him on IRC. We';ll
I've added a mandatory waf check for the libaes_siv library.
The requirement for it has been document it in INSTALL for some time;
it's required for the NTS Support we're developing.
We didn't source-include it because Daniel wants his cmake build to
keep control of the compilation environment
Hal Murray via devel :
> Are we interested in client certificates? If so, why?
>
> struct ntsconfig_t has:
> /* Configuration data for an NTS server or client instance */
> char *ca; /* site default */
> char *cert; /* site default */
>
> I assume that
Eric S. Raymond via devel :
> Hal Murray via devel :
> > It's linking ntsd which we aren't interested in so I commented it out.
>
> I should just abolish that, since you;re going to be runing key service
> from ntpd.
Have done so.
--
http://www.catb.org/~esr
Hal Murray via devel :
> It's linking ntsd which we aren't interested in so I commented it out.
I should just abolish that, since you;re going to be runing key service
from ntpd.
--
http://www.catb.org/~esr/;>Eric S. Raymond
My work is funded by the Internet Civil Engineering
Hal Murray :
> I like the strace idea. Why don't you collect some data, write the code to
> process it, and compare the results with our code? It would be interesting
> to
> see how many unused slots we have.
Because that would be silly. At best I could exercise only a tiny random sample
of
Hal Murray :
> > Very easily done. No you have a prefereence for the name?
>
> Do we want to do something now, or put it on the back burner until we find a
> good use case?
You're driving this piece of the development, and I don't see an *architectural*
reason to call that one way or the
Hal Murray via devel :
> More info via man SSL_CTX_get_security_level
>
> The default seems appropriate for now. Some people might want to tighten
> things up.
>
> We might need to set it per-client to allow a new system to use servers
> running on old systems.
Very easily done. No you have
Hal Murray :
>
> e...@thyrsus.com said:
> > What additional syscalls does it imply?
>
> I don't know. I had syscomp enabled on my test machine. The first time I
> tried NTS, it blew up, so I turned it off and went back to work on NTS.
>
> My reading on syscomp is that some tools are
Richard Laager via devel :
> Not to steer this too far off track, but is there any interest in
> shipping an Apparmor policy upstream? The file itself has a GPL-2
> license; if that's not acceptable, perhaps we could ask SUSE & Canonical
> to relicense.
That doesn't sound like a bad idea, but I
Hal Murray via devel :
>
> NTS uses libssl which adds a large can of worms to the existing pile.
>
What additional syscalls does it imply?
Dropping seccomp would be bad optics for a security-focused project.
That doesn't mean we can't do it, but we'd better be able to tell the
world a damn
Hal Murray via devel :
> I'm starting to pay attention to some of the configuration options.
>
> It seems strange to use "crypto" for the keyword when we are talking about
> NTS
> or NTS-KE.
I've already changed this to "nts".
> The documentation for crypto enable says:
> Enable NTS
Hal said someone would be a hero if they could squash it. Well...
it's squashed in upstream Bison. There's a "break" inserted at the
right spot in the skeleton with a comment about suppressing compiler
warnings.
Whatever platform you're on, the next update of the Bison package
should make this
Matthew Selsky :
> Per https://en.wikipedia.org/wiki/OpenSSL, OpenSSL added support for tls1.2
> in version 1.0.1. And that version was end of support in December 2016.
>
> So any version of OpenSSL that we encounter on a supported operating system
> will have a "new enough" OpenSSL to support
Hal Murray via devel :
> It seems strange to use "crypto" for the keyword when we are talking about
> NTS
> or NTS-KE.
I've changed the keyword to "nts".
--
http://www.catb.org/~esr/;>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute:
Hal Murray via devel :
> It seems strange to use "crypto" for the keyword when we are talking about
> NTS
> or NTS-KE.
Yes, I was planning to change that. I originally thought there were going to be
crypto options that might someday be be used for something besides NTS and
intended to have
Gary E. Miller via devel :
> > I'm debugging on OpenSSL 1.1.1a which supports TLS1.3 but is not
> > widely deployed yet.
>
> For good reason. From their wiki:
>
> https://wiki.openssl.org/index.php/TLS1.3
>
> "The OpenSSL git master branch (and the 1.1.1-pre9 beta version)
> contain
$TTL 86400
@ IN SOA thyrsus.com. root.thyrsus.com. (
8 ; serial
28800 ; refresh
7200 ; retry
604800 ; expire
86400 ; ttl
)
;;
Hal Murray :
>
> > Do you want me to write those?
>
> They are second on my list. If you do it, it will save me time.
OK. Got kung fu class tonight, but I'll work on them.
--
http://www.catb.org/~esr/;>Eric S. Raymond
My work is funded by the Internet Civil Engineering
Hal Murray :
> I'd probably put an NTS_KE_ in front of all the record_types, IANA_ on the
> crypto list, and NTP_EX_ on the NTP extension types.
No objection from here.
> Maybe:
> ntp_append_record(, type, length, , pad)
> It would byte-swap and append the type and length, copy the data, and
Hal Murray via devel :
>
> I pushed the start of NTS-KE-client code, partly in order to find things like
> this.
>
>
> Job #157857979 ( https://gitlab.com/NTPsec/ntpsec/-/jobs/157857979 )
>
> Stage: build
> Name: macos-basic
> Trace: "_res_9_init", referenced from:
> _open_TCP_socket
Hal Murray :
>
> e...@thyrsus.com said:
> >> That program would probably be handy for debugging so maybe we should write
> >> it anyway.
>
> > This sounds like you volunteering to write and test the code.
>
> I added some ugly code to my hack client to generate a canned request, and
> similar
Richard Laager via devel :
> On 2/5/19 7:49 PM, Richard Laager wrote:
> > I have a specific proposal that I'll hopefully write up tonight, which
> > may address the needs in this space.
> I did some brainstorming on this with a colleague. I initially started
> with an approach that would consider
Richard Laager via devel :
> I have (and was/am using) a clock using the Spectracom driver, with the
> two-digit year. It recently suffered from GPS rollover, so I disabled
> the GPS source in ntpd. I'm using the PPS source with network sources
> (which I was using anyway) to number the seconds.
Hal Murray :
>
> 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
Hal Murray :
>
> > 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
Hal Murray :
>
> 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
Hal Murray :
> > 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.
I see the
We have a number of tasks ahead of us, and I'm hoping for volunteers
to step up. I can't do all the code myself; I expect to have plenty on
my plate documenting things, being everybody's utility coder for the
interfaces between NTS and the rest of NTPsec, and reviewing code.
The tasks:
1.
Hal Murray :
>
> 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.
If that was going to go into nts.c
Hal Murray :
> Please make sure this gets on your list. Do you have a list for NTS or
> should
> I make an issue for it?
Please open an issue. It's not something I can give priority to at the
moment.
In fact, it's not strictly speeking something we need to fix until we're
worrieed about
Hal Murray :
> 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?
Under Linux, yes, up to 4096 bytes. Look for "I wrote a
Achim Gratz via devel :
> Matthew Selsky via devel writes:
> > See https://www.ntpsec.org/drivers.html
> >
> > INACCURATE
> > Remove GPS drivers and time radios for which the hardware offers no
> > better source accuracy than a timing GPS available for less than $75
> > in 2015; that is, about
I've been quiet about the NTS work for the last couple of days
because, off-list, I was trying to recruit the person who cooperated
with Daniel on the draft RFC and write the first server implementation
to do our client-side code.
Had I succeeded, that would have changed our planning a lot. Alas,
Hal Murray :
> 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.
Grrr. Smacks of kicking the can down the road rather than
Achim Gratz via devel :
> You can have all these errors with four digit years.
Of course we can. I'm not claiming that disqualifying these sources
with 2-digit year reports will solve the problem, just reduce the
number of failure modes and the difficulty of reasoning about them.
--
Achim Gratz via devel :
> I visited DEC in Palo Alto one time and got to see the very first Alpha
> mainboard (with an alcohol heatpipe made from a glass tube atop the
> CPU).
Damn shame about the Alpha. That was a good design that DEC utterly botched the
positioning and marketing of.
Back
I found a documentation error.
The page for the modem driver says:
This driver requires a 9600 bps modem with a Hayes-compatible command
set and control over the modem data terminal ready (DTR) control line.
The actual line speed ranges from 1200 bps with USNO to 14,400 bps
with
Richard Laager via devel :
> 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.
Thanks, it's important to know the order of magnitude of the slack there.
--
Hal Murray :
> > 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
Mark: Heads up! Policy question ahead.
Some of our remaining refclocks return only 2-digit years, relying on
the system clock to disambiguate the century.
On conventional PCs this is seldom a problem. There's a time value
returned by an RTC (real-time clock) which the kernel reads, and
changes
Richard Laager :
> On 2/3/19 1:01 PM, Eric S. Raymond wrote:
> > I guess it will have to be an empty string that disables encryption.
>
> I'm not sure if you wrote this before the recent messages on the NULL
> ciphers. But you said you were going to use that, so...
>
> It's not an empty
Richard Laager :
> If "cipher" is for TLS:
OK, that was the idea.
> Rename cipher to ciphers (plural) and add a second one named
> ciphersuites. You'll need two for testing anyway, as OpenSSL takes TLS
> 1.2 and 1.3 cipher specifications separately.
>
> Then those are just done for the final
Achim Gratz via devel :
> Eric S. Raymond via devel writes:
> > Hal Murray :
> >> 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.
>
> https://crypt
Richard Laager :
> This enclair option will only be useful for very early testing (and can
> then be removed).
OK. It was easy to add and will be easy to remove.
On a related note, the fixed complexity cost of the "crypto" command was
a bit annoying, but now that I've done it...
...the
Hal Murray :
> 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.
My plan is to brute-force the problem. Rather than trying to beat TLS into
talking en clair, I'll make 'enclair' change the socket-fu so
I have implemented and fully documented a new 'crypto' configuration
with options mintls, maxtls, and enclair. They set globals in
ntpd/nts.c.
The mintls and maxtls options are as discussed on this list. The
"enclair" option is intended to disable crypto negotiation so
certificates are not
Richard Laager via devel :
> And the question would be how to deal with a request for a port only.
> There seem like two ways to allow that:
>
> 8: ask 10123
> 9: ask :10123
>
> #9 is not ambiguous with anything, but looks weird and is almost
> ambiguous with #5, as ::10123 is an IPv6 address
Richard Laager :
> So given that tlsversions OR (tlsmin AND tlsmax) cover all the scenarios
> of forcetls, but the reverse is not true, I think you should pick one of
> those options instead of forcetls.
Done. I'll implement mintls and maxtls - that change is easy.
--
Richard Laager via devel :
> >>> Can anyone explain to me a case in which these are not
> >>> equivalent to expcit port prefixes on a server, ask, re require
> >>> address?
> >>
> >> Because the Proposed RFC says you can ask for an ntpport without
> >> asking for a ntpd address.
> >
> > Cite? I
Gary E. Miller via devel :
> > 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?
>
> No. Required for testing. Required for crypto emergencies. The
> history of Apache, nginx, postfix and
201 - 300 of 805 matches
Mail list logo
