Gary E. Miller via devel writes:
>> No, in fact my expectation is that the ntpsec implementation should
>> support an NTS pool.
>
> Which does not exist, and will take years for an RFC to create.
Well, you tell me why it absolutely needs another (or changed) RFC. As
I said before, while changes a
Richard Laager :
> On 2/2/19 1:59 AM, Eric S. Raymond via devel wrote:
> > What I *am* clear on is that we have a job to do to convince Cisco to
> > keep funding us. I want to impress them with quality and *speed* and that
> > means I am not going to go on any yak-shaving expeditions and you
> > sh
Yo Richard!
On Sat, 2 Feb 2019 17:55:22 -0600
Richard Laager via devel wrote:
> On 2/2/19 3:06 PM, Gary E. Miller via devel wrote:
> >>
> >> We have a min option.
> > As previously discussed her. A min options was tried by others in
> > the past, and failed. When SSL 2 gave way to TLS 1, the
On 2/2/19 1:59 AM, Eric S. Raymond via devel wrote:
> What I *am* clear on is that we have a job to do to convince Cisco to
> keep funding us. I want to impress them with quality and *speed* and that
> means I am not going to go on any yak-shaving expeditions and you
> shouldn't either.
Avoiding y
On 2/2/19 4:10 PM, Eric S. Raymond via devel wrote:
> Gary E. Miller via devel :
>> As previously discussed her. A min options was tried by others in the
>> past, and failed. When SSL 2 gave way to TLS 1, the min broke.
>
> Well, of *course* any minssl option stopped being useful when there was
On 2/2/19 3:06 PM, Gary E. Miller via devel wrote:
>>
>> We have a min option.
> As previously discussed her. A min options was tried by others in the
> past, and failed. When SSL 2 gave way to TLS 1, the min broke.
Huh? What's the problem here? The epoch in renumbering from SSL 2 & 3 to
TLS 1.0
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 sendmail
Yo Eric!
On Sat, 2 Feb 2019 02:59:32 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > Right, a bad thing.
>
> I'm not going to argue with you about the way configuration is now
> implemented. There are some problems with it, there are some
> advantages; I'm certainly not marri
Yo Eric!
On Sat, 2 Feb 2019 03:06:23 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > > Would somebody dig me up lists of the cipher names?
> >
> > openssl ciphers -v | fgerp TLS
> >
> > Which is incomplete since Gentoo, like almost all distros, does not
> > implement TLS
Gary E. Miller via devel :
> As previously discussed her. A min options was tried by others in the
> past, and failed. When SSL 2 gave way to TLS 1, the min broke.
Well, of *course* any minssl option stopped being useful when there was a major
interoperability break! That's an out-of-context ch
Yo Hal!
On Sat, 02 Feb 2019 00:49:48 -0800
Hal Murray via devel wrote:
> 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 bugge
Yo Eric!
On Sat, 2 Feb 2019 04:25:51 -0500
"Eric S. Raymond via devel" wrote:
> > Just because the current pool is untrustworthy doesn't mean that
> > somebody couldn't run a trusted pool.
Without crupto? No. Bad idea.
> > Keep in mind that pool+nts isn't well specified yet. Do we want to
>
Yo Achim!
On Sat, 02 Feb 2019 10:43:33 +0100
Achim Gratz via devel wrote:
> Hal Murray via devel writes:
> >> 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 untrustwort
Yo Hal!
On Sat, 02 Feb 2019 02:07:03 -0800
Hal Murray wrote:
> 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.
A typo for 'def
Yo Hal!
On Sat, 02 Feb 2019 02:53:18 -0800
Hal Murray via devel wrote:
> 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
> sho
Yo Eric!
On Sat, 2 Feb 2019 07:14:23 -0500
"Eric S. Raymond via devel" wrote:
> > 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
> >
Hal Murray via devel writes:
> 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.
Multiplexing over a single
Hal Murray via devel :
> I think we should put pool stuff on the back burner.
Agreed. Until we demonstrate TLS interop to Cisco that is where I
think everybody needs to be concentrating.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet Civil Engin
Hal Murray :
>
> >> 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.
Ah, that's t
Hal Murray :
> I believe that
> server ntp.example.com nts
> should work in many/most cases.
That was my design goal, yes.
> 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
> 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 i
>> 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 spa
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
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 ver
Hal Murray via devel writes:
>> 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.
No, in fact my expectation
Hal Murray :
> > 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.
Sorry, I didn't understand that.
> [Specifying nonsense options, like refid for
Eric S. Raymond via devel writes:
> If there's a good semantic reason to have a separate nts statement, I
> can do that. But I don't presently know of one. A request for secure time
> service has to reference an NTP server, yes?
The reason was that for NTS you do not talk to the NTP server, but t
> 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
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_pro
Hal Murray :
> What's wrong with MAC authentication when used with a good algorithm?
Nothing much. I wrote that when I thought MD5 and SHA-1 were still
all we had.
I do like removing features when they've been functionally superseded.
I lean heavily on reduction of complexity and attack surface
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 supp
Gary E. Miller via devel :
> > Would somebody dig me up lists of the cipher names?
>
> openssl ciphers -v | fgerp TLS
>
> Which is incomplete since Gentoo, like almost all distros, does not
> implement TLS 1.3. Also incomplete as I have not looked up the AEAD
> ciphers which are also differe
Gary E. Miller via devel :
> Right, a bad thing.
I'm not going to argue with you about the way configuration is now
implemented. There are some problems with it, there are some advantages;
I'm certainly not married to the way it's done now.
What I *am* clear on is that we have a job to do to con
Gary E. Miller via devel :
> > The nonorthogonality of one nts declaration head versus one option
> > flag, when it could have been two similar option flags, would
> > be too ugly to live.
>
> I think we differ on which non-orthoganality is worst.
Evidently.
The difference is, the responsibility
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 go
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 docs/incl
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.
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 that
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' stateme
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. That
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 obv
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]* R
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 *a
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 obv
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.
Wh
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 di
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 wrap
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
t
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
M
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. The
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 is
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 pa
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 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
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 everyon
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 server
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, invit
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 impl
63 matches
Mail list logo
