> I thought that you, Gary, and I were in favor of random keys (as opposed to
> ratchet), nobody was speaking against that, and nobody was in favor of
> ratcheting (at least in a non-pool case).
Ahh... I haven't written the ratchet code. It's not high on my list, But
I'm trying to keep the
On 3/8/19 8:43 PM, Hal Murray wrote:
> rlaa...@wiktel.com said:
>>> The draft suggests a way to derive the next key from the current key.
>> I thought there was a rough consensus here to avoid that, using
>> fully-random keys each time.
>
> I don't remember that. Any chance you can find it in th
rlaa...@wiktel.com said:
>> The draft suggests a way to derive the next key from the current key.
> I thought there was a rough consensus here to avoid that, using
> fully-random keys each time.
I don't remember that. Any chance you can find it in the archives?
--
These are my opinions. I
Yo Richard!
On Fri, 8 Mar 2019 11:46:10 -0600
Richard Laager via devel wrote:
> On 3/7/19 9:11 PM, Hal Murray wrote:
> > The draft suggests a way to derive the next key from the current
> > key.
> I thought there was a rough consensus here to avoid that, using
> fully-random keys each time.
I
On 3/7/19 9:11 PM, Hal Murray wrote:
> The draft suggests a way to derive the next key from the current key.
I thought there was a rough consensus here to avoid that, using
fully-random keys each time.
--
Richard
___
devel mailing list
devel@ntpsec.org
Yo Hal!
On Thu, 07 Mar 2019 22:39:12 -0800
Hal Murray via devel wrote:
> > I cant find that in the Proposed RFC. Got a citation?
>
> Bottom of page 21. Last paragraph of section 5.
Ah, there it is:
"To allow for NTP session restart when the NTS-KE server is
unavailable and to reduce
> I cant find that in the Proposed RFC. Got a citation?
Bottom of page 21. Last paragraph of section 5.
> And what is the point of storing cookies and K/I pair together? The client
> has no K/I pair. A server is to regenerate the cookies from K/I pairs.
> Mixing the roles is bad.
I didn't s
Yo Hal!
On Thu, 07 Mar 2019 21:21:01 -0800
Hal Murray via devel wrote:
> Gary said.
> > I think it should be master key "K" and index "I" pairs. Only.
>
> The K includes the length. There are actually 3 algorithms that can
> be used on the wire or to make cookies. The wire has a slot for
>
Gary said.
> I think it should be master key "K" and index "I" pairs. Only.
The K includes the length. There are actually 3 algorithms that can be used
on the wire or to make cookies. The wire has a slot for which algorithm to
use. The internal API is to pass the same routine different key l
Yo Hal!
On Thu, 07 Mar 2019 19:11:59 -0800
Hal Murray via devel wrote:
> > If the cookie key file is unexpectedly removed, what other useful
> > option is there? If the file was permanently deleted, there's
> > really nothing to be done but re-create it anyway.
>
> The question is does the a
> If the cookie key file is unexpectedly removed, what other useful option is
> there? If the file was permanently deleted, there's really nothing to be done
> but re-create it anyway.
The question is does the admin know something happened.
> Also, by the way, the cookie key file is storing th
Hal Murray :
>
> Eric said:
> > This raises an interesting point. ntpd can now tell when its on first
> > startup (absence of this file). I'm not a fan of this kind of statefulness
> > -
> > worked hard at avoiding it in GPSD - but since NTS's requirements stick us
> > with it there's a questio
On 3/7/19 8:50 PM, Hal Murray via devel wrote:
> Creating it when it doesn't exist means it will do the wrong thing if the
> file
> gets unexpectedly removed.
If the cookie key file is unexpectedly removed, what other useful option
is there? If the file was permanently deleted, there's really no
Eric said:
> This raises an interesting point. ntpd can now tell when its on first
> startup (absence of this file). I'm not a fan of this kind of statefulness -
> worked hard at avoiding it in GPSD - but since NTS's requirements stick us
> with it there's a question: what else should trigger o
e...@thyrsus.com said:
>> Can we and/or should we make the default file names OS dependent?
> I recommend trying to avoid that. Follow the Filesystem Hierarchy Standard
> and let other OSes be their local packagers' problem.
That seems reasonable, but only if you provide an easy way for the pac
Yo Daniel!
On Thu, 7 Mar 2019 17:18:28 -0500
Daniel Franke wrote:
> On Thu, Mar 7, 2019 at 5:14 PM Gary E. Miller via devel
> wrote:
> > Wikipedia makes no mention, even sideways, of /var/local.
> >
> > Nor does the base document, FHS 3.0:
> > https://refspecs.linuxfoundation.org/FHS_3.
On Thu, Mar 7, 2019 at 5:14 PM Gary E. Miller via devel
wrote:
> Wikipedia makes no mention, even sideways, of /var/local.
>
> Nor does the base document, FHS 3.0:
> https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf
>
> See section 5. "The /var Hierarchy".
It's specified in the tab
Yo Daniel!
On Thu, 7 Mar 2019 16:19:34 -0500
Daniel Franke wrote:
> On Thu, Mar 7, 2019 at 3:10 PM Gary E. Miller via devel
> wrote:
> > My idiosyncratic read of the FHS would, by default, put the master
> > keys in /usr/local/var/lib:
> >
> > "State information. Persistent data modified by pro
Yo Hal!
On Thu, 07 Mar 2019 13:51:33 -0800
Hal Murray via devel wrote:
> Gary said:
> > Remeber, user installed codes should NEVER use /usr or /var.
> > I do realize this is a rule frequently violated, but givin how
> > often users install both the distro ntpd/gpsd and the source
> > ntpd/gpsd i
Yo Hal!
On Thu, 07 Mar 2019 13:29:58 -0800
Hal Murray via devel wrote:
> > Documentation isn't a problem. The docs can and should get the same
> > waf subst behavior anyway. So the docs should always mention the
> > paths that match how I built my ntpd.
>
> That gets interesting. Many copie
Gary said:
> Remeber, user installed codes should NEVER use /usr or /var.
> I do realize this is a rule frequently violated, but givin how often users
> install both the distro ntpd/gpsd and the source ntpd/gpsd it is good to keep
> their files in different places.
Interesting. But this is som
> Documentation isn't a problem. The docs can and should get the same waf subst
> behavior anyway. So the docs should always mention the paths that match how I
> built my ntpd.
That gets interesting. Many copies of documentation end up on the web. Can
we arrange things so the default says so
On Thu, Mar 7, 2019 at 3:10 PM Gary E. Miller via devel
wrote:
> My idiosyncratic read of the FHS would, by default, put the master keys
> in /usr/local/var/lib:
>
> "State information. Persistent data modified by programs as they run,
> e.g., databases, packaging system metadata, etc. "
I have n
Yo Richard!
On Thu, 7 Mar 2019 15:00:44 -0600
Richard Laager via devel wrote:
> On 3/7/19 2:44 PM, Hal Murray via devel wrote:
> > Gary said:
> >> My idiosyncratic read of the FHS would, by default, put the master
> >> keys in /usr/local/var/lib:
> >
> > Is that a typo? There is no /usr/l
On 3/7/19 2:44 PM, Hal Murray via devel wrote:
> Gary said:
>> My idiosyncratic read of the FHS would, by default, put the master keys in
>> /usr/local/var/lib:
>
> Is that a typo? There is no /usr/local/var/ or /usr/var/ on Fedora or Debian.
It might be reasonable to default to $PREFIX/var/lib
Yo Hal!
On Thu, 07 Mar 2019 12:44:40 -0800
Hal Murray via devel wrote:
> Gary said:
> > My idiosyncratic read of the FHS would, by default, put the master
> > keys in /usr/local/var/lib:
>
> Is that a typo?
No.
> There is no /usr/local/var/ or /usr/var/ on Fedora
> or Debian.
Now would th
Gary said:
> My idiosyncratic read of the FHS would, by default, put the master keys in
> /usr/local/var/lib:
Is that a typo? There is no /usr/local/var/ or /usr/var/ on Fedora or Debian.
> We can pick a default, but no default would be fine for most linux.
> It needs to be configurable for
Yo Achim!
On Thu, 07 Mar 2019 21:13:47 +0100
Achim Gratz via devel wrote:
> Hal Murray via devel writes:
> > They are needed to use old cookies after restarting ntpd.
>
> I'd not go there. If you do a cold restart, you lose the
> cryptographic state, end of story.
Now imagine you are runnin
Hal Murray via devel writes:
> They are needed to use old cookies after restarting ntpd.
I'd not go there. If you do a cold restart, you lose the cryptographic
state, end of story. Now, doing a warm restart that doesn't lose all
state is something that's useful independent of the topics around N
Yo Richard!
On Thu, 7 Mar 2019 13:59:36 -0600
Richard Laager via devel wrote:
> On 3/7/19 1:07 PM, Eric S. Raymond wrote:
> > Dissenting mildly. For reasons I've explained before I'm trying to
> > move us away from config options. I will be resistant to adding
> > more in the future. Doesn't m
On 3/7/19 1:07 PM, Eric S. Raymond wrote:
> Dissenting mildly. For reasons I've explained before I'm trying to move us
> away from config options. I will be resistant to adding more in the future.
> Doesn't mean that we can never do it, but I'd want to see a demonstration of
> need in each indivi
>> Where should we put the file used to store the key used to make cookies?
It
>> gets read at startup and updated daily.
> Nowhere. Those keys are ephemeral and shouldn't be stored at all, except
> maybe for debugging.
They are needed to use old cookies after restarting ntpd.
A side benefi
Achim Gratz via devel :
> Hal Murray via devel writes:
> > Where should we put the file used to store the key used to make cookies?
> > It
> > gets read at startup and updated daily.
>
> Nowhere. Those keys are ephemeral and shouldn't be stored at all,
> except maybe for debugging.
I think yo
Richard Laager via devel :
> Either /var/lib/ntp, or as suggested in a previous message, /var/NTP
> seems fine for the default. The important part is discussed below.
I concur. I think I'd prefer the former slightly, but that's a pure
matter of taste (I dislike caps in filenames) so Hal gets to m
Yo Achim!
On Thu, 07 Mar 2019 19:41:05 +0100
Achim Gratz via devel wrote:
> Hal Murray via devel writes:
> > Where should we put the file used to store the key used to make
> > cookies? It gets read at startup and updated daily.
>
> Nowhere. Those keys are ephemeral and shouldn't be stored
Hal Murray via devel writes:
> Where should we put the file used to store the key used to make cookies? It
> gets read at startup and updated daily.
Nowhere. Those keys are ephemeral and shouldn't be stored at all,
except maybe for debugging.
> Fedora and Debian put things like that in /var/li
On 3/7/19 6:43 AM, Eric S. Raymond via devel wrote:
> Hal Murray via devel :
>>
>> Where should we put the file used to store the key used to make cookies? It
>> gets read at startup and updated daily.
>>
>> Fedora and Debian put things like that in /var/lib/ntp/
>> NetBSD and FreeBSD put them in
Hal Murray via devel :
>
> Where should we put the file used to store the key used to make cookies? It
> gets read at startup and updated daily.
>
> Fedora and Debian put things like that in /var/lib/ntp/
> NetBSD and FreeBSD put them in /var/db/ntp/
Given that we don't have any intrinsic tech
On 3/6/19, Hal Murray via devel wrote:
>
> Where should we put the file used to store the key used to make cookies? It
>
> gets read at startup and updated daily.
>
> Fedora and Debian put things like that in /var/lib/ntp/
> NetBSD and FreeBSD put them in /var/db/ntp/
>
> There used to be a man/w
Where should we put the file used to store the key used to make cookies? It
gets read at startup and updated daily.
Fedora and Debian put things like that in /var/lib/ntp/
NetBSD and FreeBSD put them in /var/db/ntp/
There used to be a man/web page with a list of the default file names. I
ca
40 matches
Mail list logo
