Gary E. Miller via devel writes:
>> Optionally, yes. I think this part of the RFC is poorly thought out,
>> I'd prefer if the NTS-KE just straight failed if the server you
>> specified is not available.
>
> I'm not sure why it has to be in the NTS-KE server. The client is free
> to accept or
Gary E. Miller via devel writes:
>> Both keys should only ever be used by a single client/server pair.
>
> Yeah, but no way to enforce that. A black-, white-, or gray-hat could
> easily reuse the same keys on thousands of servers at the same time.
There is a virtual guarantee of unique keys if
I was reviewing documentation today and discovered something alarming.
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.
The last person to work on this seems to have
Yo Richard!
On Fri, 1 Feb 2019 21:24:06 -0600
Richard Laager via devel wrote:
> On 2/1/19 9:07 PM, Richard Laager wrote:
> > On 2/1/19 7:56 PM, Gary E. Miller via devel wrote:
> >> "tlsver [1.2 1.3]*
> > If forcing a maximum version (e.g. for testing) is important, tlsver
> > seems like a
Yo Eric!
On Fri, 1 Feb 2019 23:13:53 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > Well, it was in nts.adoc, after consensus had been reached, before
> > Eric removed it.
>
> Everything I removed I removed because I implemented it and descrubed
> the new options in
Yo Eric!
On Sat, 2 Feb 2019 00:30:07 -0500 (EST)
"Eric S. Raymond via devel" wrote:
> >*tls1.2* Allow TLS1.2 connection.
> >
> >*tls1.3* Allow TLS1.3 connection.
>
> They'd be easy, but I have two issues with these. First, I want
> embedded punctuation out of the names - I don't want that
>
Yo Eric!
On Fri, 1 Feb 2019 23:29:40 -0500
"Eric S. Raymond via devel" wrote:
> Long mail heading your way on this topic, but the TL;DR is that
> it needs to be "server foo nts" in case we ever need to have a pool
> nts flag (which I think is likely).
Which is not possible in any safe manner.
>From nts.adoc
>*tlsport XXX* Contact the NTS-KE server on TCP port XXX.
>
>*ntpport YYY* Request an NTPD server on UDP port YYY.
These are easy. If I don't do them before I sleep they'll be in place
some time tomorrow.
>*ask [address]* Request a particular NTPD server, but do not require
>it.
Yo Eric!
+nts+::
Use Network Time Security for authentication and encryption.
- Request key exchange from the NTP server.
+ Request key exchange from the NTP server. Following options
+ are revelevant only for nts peers, and are thus tagged with 'nts'.
+ that can be omitted when the
Yo Eric!
On Fri, 1 Feb 2019 22:45:10 -0500
"Eric S. Raymond" wrote:
> > Right, and if we use the 'nts' keyword, that is no longer the
> > case.
>
> Incorrect. A new declaration head keyword by itself cannot fix any
> problem at all. Not the problem you think you have, and no other
> problem
Hal Murray via devel :
>
> 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
Gary E. Miller via devel :
> Well, it was in nts.adoc, after consensus had been reached, before Eric
> removed it.
Everything I removed I removed because I implemented it and descrubed
the new options in docs/includes.assoc-options.adoc
From now on, you can assume that if I remove stuff from
Gary E. Miller via devel :
> Yo Eric!
>
> On Fri, 1 Feb 2019 16:53:37 -0500
> "Eric S. Raymond" wrote:
>
> > Gary E. Miller via devel :
> > > > If there's a good semantic reason to have a separate nts
> > > > statement, I can do that.
> > >
> > > The options for the 'nts' and 'server'
On 2/1/19 9:07 PM, Richard Laager wrote:
> On 2/1/19 7:56 PM, Gary E. Miller via devel wrote:
>> "tlsver [1.2 1.3]*
> If forcing a maximum version (e.g. for testing) is important, tlsver
> seems like a good approach.
Another approach would be to allow specifying a minimum and maximum
version.
On 2/1/19 7:56 PM, Gary E. Miller via devel wrote:
> "tlsver [1.2 1.3]*
If forcing a maximum version (e.g. for testing) is important, tlsver
seems like a good approach.
> So, which of these should be just 'ciphers': tls1.2ciphers, tls1.3ciphers,
> or ntpciphers? And it has to be rediculously
Yo Richard!
On Fri, 1 Feb 2019 18:35:49 -0600
Richard Laager via devel wrote:
> FWIW, I think you've sold me on why we need "nts" separate from
> "server". There are a LOT of extra options for NTS.
13, and counting.
> On 2/1/19 4:51 PM, Gary E. Miller via devel wrote:
> > *require [address]*
On 2/1/19 5:24 PM, Hal Murray via devel wrote:
> 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.
Yep.
> But that
> translation step adds another layer of security considerations.
It's
FWIW, I think you've sold me on why we need "nts" separate from
"server". There are a LOT of extra options for NTS.
On 2/1/19 4:51 PM, Gary E. Miller via devel wrote:
> *require [address]* Require a particular NTPD server, fail if it is not
> the NTPD sevver address returned. Otherwise same as
Yo Hal!
On Fri, 01 Feb 2019 15:24:09 -0800
Hal Murray via devel wrote:
> 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.
Yup, but not always. Some will want to stop on mismatch, some want
Yo Hal!
On Fri, 01 Feb 2019 15:07:41 -0800
Hal Murray via devel wrote:
> 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?
TL:DR: They are very different, the syntax should make it
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
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.
Yo Hal!
On Fri, 01 Feb 2019 14:21:25 -0800
Hal Murray wrote:
> 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
Yo Eric!
On Fri, 1 Feb 2019 17:24:15 -0500
"Eric S. Raymond via devel" wrote:
> > with being a normal declaration. I can see this becoming
> > confusing due to refclocks looking like they would slot in, but
> > don't.
>
> Yep.
Lost me. How did refclocks get in here?
> Also, nts as a
Ian Bruene via devel :
>
>
> On 2/1/19 3:53 PM, Eric S. Raymond via devel wrote:
> > What is the natural kind in which "nts" is an alternative to "server",
> > "pool", and "refclock"? If there is such a kind, how does that square
> > with the possibility that "nts" may become a property of pool
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
Gary E. Miller via devel :
> > > What structure name?
> >
> > struct ntscfg_t, in include/nts.h
>
> Oh, my. I suggest you re-read nts.adoc. About a dozen missing
> variables. Maybe a half a dozen more items to come.
Will do.
--
http://www.catb.org/~esr/;>Eric S. Raymond
Yo Eric!
On Fri, 1 Feb 2019 17:03:02 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > Uh, sorry, too many threads. What was the context?
>
> https://lists.ntpsec.org/pipermail/devel/2019-February/007335.html
Added to nts.adoc,
RGDS
GARY
Yo Eric!
On Fri, 1 Feb 2019 16:56:53 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > On Fri, 1 Feb 2019 10:19:53 -0500 (EST)
> > "Eric S. Raymond via devel" wrote:
> >
> > > I have enhanced the configuration parser to process NTS
> > > client-side configuration options.
Yo Eric!
On Fri, 1 Feb 2019 16:53:37 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > > If there's a good semantic reason to have a separate nts
> > > statement, I can do that.
> >
> > The options for the 'nts' and 'server' statements in the config file
> > will be different.
On 2/1/19 3:53 PM, Eric S. Raymond via devel wrote:
What is the natural kind in which "nts" is an alternative to "server",
"pool", and "refclock"? If there is such a kind, how does that square
with the possibility that "nts" may become a property of pool request
instances?
Possibly if nts
Gary E. Miller via devel :
> Uh, sorry, too many threads. What was the context?
https://lists.ntpsec.org/pipermail/devel/2019-February/007335.html
--
http://www.catb.org/~esr/;>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Gary E. Miller via devel :
> On Fri, 1 Feb 2019 10:19:53 -0500 (EST)
> "Eric S. Raymond via devel" wrote:
>
> > I have enhanced the configuration parser to process NTS client-side
> > configuration options. The configuration state is available to the
> > nts.c hooks as members of a structure
Gary E. Miller via devel :
> > If there's a good semantic reason to have a separate nts statement, I
> > can do that.
>
> The options for the 'nts' and 'server' statements in the config file
> will be different. Trying to merge them will confuse everyone.
Heh. The "confuse" ship has long since
Yo Eric!
On Fri, 1 Feb 2019 15:33:53 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > This prolly needs to be brought up to the WG.
>
> Please add it to the open issues section in nts.adoc.
Uh, sorry, too many threads. What was the context?
RGDS
GARY
Gary E. Miller via devel :
> This prolly needs to be brought up to the WG.
Please add it to the open issues section in nts.adoc.
--
http://www.catb.org/~esr/;>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site
Yo James!
I doubt anyone here knows ebuilds. All yours.
On Thu, 31 Jan 2019 20:15:53 -0800
James Browning via devel wrote:
> On 1/31/19, Gary E. Miller via devel wrote:
> > Yes. But not done. It likely broke the current Gentoo NTPsec
> > ebuild for git head.
>
> I have a patch for that.
Yo Hal!
On Fri, 01 Feb 2019 11:11:14 -0800
Hal Murray via devel wrote:
> 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.
Too late. How to make the pool
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
Yo Hal!
On Fri, 01 Feb 2019 10:23:26 -0800
Hal Murray via devel wrote:
> 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
Yo Eric!
On Fri, 1 Feb 2019 10:19:53 -0500 (EST)
"Eric S. Raymond via devel" wrote:
> I have enhanced the configuration parser to process NTS client-side
> configuration options. The configuration state is available to the
> nts.c hooks as members of a structure passed to them, along with the
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
Yo Eric!
On Fri, 1 Feb 2019 12:34:34 -0500
"Eric S. Raymond via devel" wrote:
> If there's a good semantic reason to have a separate nts statement, I
> can do that.
The options for the 'nts' and 'server' statements in the config file
will be different. Trying to merge them will confuse
On 2/1/19 11:34 AM, Eric S. Raymond wrote:
> Richard Laager via devel :
>> On 2/1/19 9:19 AM, Eric S. Raymond via devel wrote:
>>> Having a separate nts config statement would have required admins to
>>> enter the name of a server to which secure connection is intended
>>> twice, once in the
Richard Laager via devel :
> On 2/1/19 9:19 AM, Eric S. Raymond via devel wrote:
> > Having a separate nts config statement would have required admins to
> > enter the name of a server to which secure connection is intended
> > twice, once in the server declaration and once in the nts declaration.
On 2/1/19 9:19 AM, Eric S. Raymond via devel wrote:
> Having a separate nts config statement would have required admins to
> enter the name of a server to which secure connection is intended
> twice, once in the server declaration and once in the nts declaration.
> This was suboptimal design,
Mostly for Ian, who was trying to recall where he left off with ntpsnmpd.
I had a working ntpsnmpd instance running on a workstation which has, sadly,
been consumed by entropy along with the rest of the assay I was using. However,
I do recall that I had a Cacti instance collecting data from
I have enhanced the configuration parser to process NTS client-side
configuration options. The configuration state is available to the
nts.c hooks as members of a structure passed to them, along with the
dynamic NTS state (stored cookies) and the parsed content of the
current packet.
What is
Richard Laager :
> On 1/31/19 10:24 PM, Eric S. Raymond wrote:
> > Replacing Python with Go should happen first for these reasons:
> >
> > (a) It's much easier than replacing the C. Thus, it will give those of us
> > with weak or noexistent Go skills time and room to ramp up. (Ian and I are
> >
49 matches
Mail list logo
