Gary E. Miller via devel writes:
>> > > But if no packets are lost, C2S and S2C will be used forever.
>> >
>> > Yeah, bad.
>>
>> 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
Gary E. Miller via devel writes:
>> Again, it supports it exactly the same way as the pool is currently
>> working with DNS: You want another server, you ask another time.
>
> Exactly why it is broken. No crypto. Unless you mean having an NTS-KE
> server manage a pool. in chich case there is zero
Yo James!
On Sat, 2 Feb 2019 18:39:56 -0800
James Browning via devel wrote:
> > I assume you mane this:
>
> Yep, this is it.
Good, we're getting on the same page.
> > Good. More correct to say stop using the same C2S/S2C
>
> Sometime after I wrote that I have the idea of using an MJD nu
On 2/2/19, Gary E. Miller via devel wrote:
> Yo James!
>
> On Sat, 2 Feb 2019 13:44:12 -0800
> James Browning via devel wrote:
>
>> >> 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 gapin
Yo James!
On Sat, 2 Feb 2019 13:44:12 -0800
James Browning via devel wrote:
> >> 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.
> >
> >> You might want to look at
Yo Richard!
On Sat, 2 Feb 2019 17:57:12 -0600
Richard Laager via devel wrote:
> On 2/2/19 3:29 PM, Gary E. Miller via devel wrote:
> > Nothing says that a single cookie could not be used by a farm of
> > clients to push the cookies per second into the thousands.
>
> The cookie, or more import
On 2/2/19 3:29 PM, Gary E. Miller via devel wrote:
> Nothing says that a single cookie could not be used by a farm of
> clients to push the cookies per second into the thousands.
The cookie, or more importantly the C2S and S2C inside of it, which is
what we are discussing here, comes from a single
Yo Achim!
On Sat, 02 Feb 2019 09:32:34 +0100
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> >> I think there is a reasonable parallel between get another server
> >> via DNS and get another server via NTS-KE.
> >
> > Yes, except the protocol, as defined in the Proposed RFC,
On 2/2/19, Gary E. Miller via devel wrote:
> Yo James!
>
> On Sat, 2 Feb 2019 13:04:25 -0800
> James Browning via devel wrote:
>
>> > > But if no packets are lost, C2S and S2C will be used forever.
>> >
>> > Yeah, bad.
>>
>>
>> What you almost need is a cookie extension to trigger a rekeying
>> p
Yo Hal!
On Sat, 02 Feb 2019 02:33:56 -0800
Hal Murray via devel wrote:
> 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://m
Gary E. Miller via devel :
> Yo James!
>
> On Sat, 2 Feb 2019 13:04:25 -0800
> James Browning via devel wrote:
>
> > > > But if no packets are lost, C2S and S2C will be used forever.
> > >
> > > Yeah, bad.
> >
> >
> > What you almost need is a cookie extension to trigger a rekeying
> > per
On Sat, Feb 2, 2019, 12:46 PM Gary E. Miller via devel Yo Hal!
>
> On Sat, 02 Feb 2019 12:36:10 -0800
> Hal Murray via devel wrote:
>
> > 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 mec
Yo James!
On Sat, 2 Feb 2019 13:04:25 -0800
James Browning via devel wrote:
> > > But if no packets are lost, C2S and S2C will be used forever.
> >
> > Yeah, bad.
>
>
> What you almost need is a cookie extension to trigger a rekeying
> periodically.
Yes. Sad the Proposed RFC is silent on
Yo Hal!
On Sat, 02 Feb 2019 12:36:10 -0800
Hal Murray via devel wrote:
> 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.
Really? So
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 an
On Sat, Feb 2, 2019, 5:27 AM Hal Murray via devel
> > 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
> > secon
> 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 o
Hal Murray via devel writes:
>> 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.
>
> D
> 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 cover
Gary E. Miller via devel writes:
>> I think there is a reasonable parallel between get another server via
>> DNS and get another server via NTS-KE.
>
> Yes, except the protocol, as defined in the Proposed RFC, does not support it.
Again, it supports it exactly the same way as the pool is currently
Richard Laager via devel writes:
> I agree that would be required to pin it. I wasn't asking to pin it by
> default, just if ntpd should (as a client) always send a Server
> Negotiation record. Given it's not required by the draft, it sounds like
> you and Gary are leaning toward "no".
For the rec
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 reje
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 ea
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
--
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
Pleas
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 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 ther
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
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
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 integ
Yo Eric!
On Thu, 31 Jan 2019 17:26:31 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > I think the current proposal works:
> >
> > nts nts-ke.example.com
> > nts nts-ke.example.com ask ntp.example.com
> > nts nts-ke.example.com require ntp.example.com
> >
> > Maybe expanded to a
Yo Richard!
On Thu, 31 Jan 2019 16:45:01 -0600
Richard Laager via devel wrote:
> On 1/31/19 12:46 PM, Achim Gratz via devel wrote:
> > Richard Laager via devel writes:
> >> Here's another wrinkle. Does the first example, "nts
> >> nts-ke.example.org", send a request for "nts-ke.example.org"? I
Yo Hal!
On Thu, 31 Jan 2019 14:47:47 -0800
Hal Murray via devel wrote:
> > 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
> 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 efficien
On 1/31/19 12:46 PM, Achim Gratz via devel wrote:
> Richard Laager via devel writes:
>> Here's another wrinkle. Does the first example, "nts
>> nts-ke.example.org", send a request for "nts-ke.example.org"? I think it
>> should.
>
> The RFC doesn't have an explicit preference, but it's implied that
On 1/31/19 3:53 PM, Gary E. Miller via devel wrote:
> I think the current proposal works:
>
> nts nts-ke.example.com
> nts nts-ke.example.com ask ntp.example.com
> nts nts-ke.example.com require ntp.example.com
>
> Maybe expanded to ask for 3 pool servers:
>
> nts nts-ke.example.com pool 3
I li
Gary E. Miller via devel :
> I think the current proposal works:
>
> nts nts-ke.example.com
> nts nts-ke.example.com ask ntp.example.com
> nts nts-ke.example.com require ntp.example.com
>
> Maybe expanded to ask for 3 pool servers:
>
> nts nts-ke.example.com pool 3
Write this up in more detauil
Achim Gratz via devel :
> Eric S. Raymond via devel writes:
> > Still not textual.
>
> I'm not sure why you'd insist on textual representations, but ASCII-Hex
> is something I'd frown upon. S-Records in particular is something that
> was useful for ROM dumps, but not wire-protocols.
Eyeball-frie
Yo Achim!
On Thu, 31 Jan 2019 19:33:49 +0100
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> >> The same as if you never get an answer from any other random server
> >> you tried to contact for whatever reason through a proxy.
> >
> > But it DOES give you an answer back.
>
Yo Achim!
On Thu, 31 Jan 2019 22:19:14 +0100
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> > The C2S and S2C already get reused millions of times, what's a few
> > more million?
>
> Both keys should only ever be used by a single client/server pair.
Yeah, but no way to enf
Eric S. Raymond via devel writes:
> Still not textual.
I'm not sure why you'd insist on textual representations, but ASCII-Hex
is something I'd frown upon. S-Records in particular is something that
was useful for ROM dumps, but not wire-protocols.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305
Gary E. Miller via devel writes:
> The C2S and S2C already get reused millions of times, what's a few more
> million?
Both keys should only ever be used by a single client/server pair.
These are symmetric keys, so whoever knows them can encrypt and decrypt
all messages that use them. So sharing t
Gary E. Miller via devel :
> We prolly need to start a doc somewhere for what we want answered.
Start a new section in nts.adoc, please. In fact, I'll do it now.
Done. Achim, you were complaining about underspecification. Please
describe your issues in this succession. We'll have someone at th
Achim Gratz via devel :
> Eric S. Raymond via devel writes:
> > Gary E. Miller via devel :
> >> Next virtual meeting of the NTP WG is Feb 12. Maybe we should get some
> >> of these issues on their agenda?
> >
> > If there's another revision in process, I want to object to the binary
> > request fo
Yo Achim!
On Thu, 31 Jan 2019 21:16:25 +0100
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> >> I think you'd
> >> need to reconnect to the NTS-KE, but at least need to re-key the
> >> TLS session
> >
> > Why? To get new C2S and S2C?
>
> Yes.
The C2S and S2C already get
Yo Eric!
On Thu, 31 Jan 2019 15:18:56 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > Next virtual meeting of the NTP WG is Feb 12. Maybe we should get
> > some of these issues on their agenda?
>
> If there's another revision in process,
Dunno about that. All we can do is
Eric S. Raymond via devel writes:
> Gary E. Miller via devel :
>> Next virtual meeting of the NTP WG is Feb 12. Maybe we should get some
>> of these issues on their agenda?
>
> If there's another revision in process, I want to object to the binary
> request format. Raises endianness issues for no
Gary E. Miller via devel :
> Next virtual meeting of the NTP WG is Feb 12. Maybe we should get some
> of these issues on their agenda?
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
Gary E. Miller via devel writes:
>> I think you'd
>> need to reconnect to the NTS-KE, but at least need to re-key the TLS
>> session
>
> Why? To get new C2S and S2C?
Yes.
>> before asking for the next server in that scenario.
>
> Which is the big issue. How does an NTPD client connect to an NTS
Yo Achim!
On Thu, 31 Jan 2019 20:02:27 +0100
Achim Gratz via devel wrote:
> The RFC is underspecified w.r.t. pools in my opinion,
Yup.
> I think you'd
> need to reconnect to the NTS-KE, but at least need to re-key the TLS
> session
Why? To get new C2S and S2C?
> before asking for the next s
Richard Laager via devel writes:
> On 1/30/19 2:32 PM, Achim Gratz via devel wrote:
>> Again, leave server for plain NTP and use a new keyword.
>
> Perhaps you already did and I missed it, but can you explain why we need
> a new top-level keyword rather than an option?
That creates an easily recog
Richard Laager via devel writes:
> The client sending a Server Negotiation record is functionally very
> similar to SNI, where a TLS client tells the TLS server the hostname it
> is using: https://en.wikipedia.org/wiki/Server_Name_Indication
>
> This is used with HTTPS to implement virtual hosting-
Richard Laager via devel writes:
> On 1/30/19 2:37 PM, Gary E. Miller via devel wrote:
>> Sure there is, we now have a choice that did not formerly exist, and I
>> can see uses for both:
>>
>> 1. If we do not get desired server: fail
>> 2. If we do not get desired server: use the offered one inste
Gary E. Miller via devel writes:
>> The same as if you never get an answer from any other random server
>> you tried to contact for whatever reason through a proxy.
>
> But it DOES give you an answer back.
Optionally, yes. I think this part of the RFC is poorly thought out,
I'd prefer if the NTS-
On 1/30/19 5:14 PM, Gary E. Miller via devel wrote:
> On Wed, 30 Jan 2019 16:59:28 -0600
> Richard Laager via devel wrote:
>
>> There's another complication too. The server can send back a name or
>> an IP address. What happens if the client request contains a name and
>> the server's response co
Yo Richard!
On Wed, 30 Jan 2019 16:59:28 -0600
Richard Laager via devel wrote:
> There's another complication too. The server can send back a name or
> an IP address. What happens if the client request contains a name and
> the server's response contains an IP? That might be a match (e.g. if
> t
On 1/30/19 2:37 PM, Gary E. Miller via devel wrote:
> Sure there is, we now have a choice that did not formerly exist, and I
> can see uses for both:
>
> 1. If we do not get desired server: fail
> 2. If we do not get desired server: use the offered one instead
>
> #2 is new to NTS.
>
> For an un
On 1/30/19 2:32 PM, Achim Gratz via devel wrote:
> Again, leave server for plain NTP and use a new keyword.
Perhaps you already did and I missed it, but can you explain why we need
a new top-level keyword rather than an option?
What is your config proposal for handling pools? Note that the
fundam
Yo Richard!
On Wed, 30 Jan 2019 15:25:47 -0600
Richard Laager via devel wrote:
> On 1/30/19 1:41 PM, Gary E. Miller via devel wrote:
> > On Wed, 30 Jan 2019 01:19:08 -0600
> > Richard Laager via devel wrote:
> >
> >> So in this example, you have ntp.example.com as the NTS-KE server,
> >> and
On 1/30/19 1:41 PM, Gary E. Miller via devel wrote:
> On Wed, 30 Jan 2019 01:19:08 -0600
> Richard Laager via devel wrote:
>
>> So in this example, you have ntp.example.com as the NTS-KE server, and
>> 1.2.3.4 or bob.example.com as the NTP servers? I assume it has to be
>> that way, as TLS doesn'
Yo Achim!
On Wed, 30 Jan 2019 21:32:57 +0100
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> > I can see value in this for testing, but IMHO it should be
> > discouraged for general use. I'd like the new ntp.conf syntax to
> > somehow emphasize that this is discouraged and opt
Gary E. Miller via devel writes:
> I can see value in this for testing, but IMHO it should be discouraged
> for general use. I'd like the new ntp.conf syntax to somehow emphasize
> that this is discouraged and optional.
No. There are several institutions that have multiple servers of which
the u
Yo Achim!
On Wed, 30 Jan 2019 20:44:31 +0100
Achim Gratz via devel wrote:
> Hal Murray via devel writes:
> >> 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
>
Yo Richard!
On Wed, 30 Jan 2019 01:18:38 -0600
Richard Laager via devel wrote:
> On 1/29/19 6:11 PM, Gary E. Miller via devel wrote:
> > Which conflicts with the Proposed RFC which says the NTS-KE tells us
> > which NTPD server, not the config file.
>
> The draft supports a mechanism wherein
Hal Murray via devel writes:
>> 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.
No, the client doesn't need to do anything special for pool servers
anymore, since t
Yo Richard!
On Wed, 30 Jan 2019 01:19:08 -0600
Richard Laager via devel wrote:
> So in this example, you have ntp.example.com as the NTS-KE server, and
> 1.2.3.4 or bob.example.com as the NTP servers? I assume it has to be
> that way, as TLS doesn't work _in practice_ (yes, I know it is
> suppor
On 1/29/19 6:11 PM, Gary E. Miller via devel wrote:
> Which conflicts with the Proposed RFC which says the NTS-KE tells us
> which NTPD server, not the config file.
The draft supports a mechanism wherein the client can request an NTP
server from the NTS-KE server.
--
Richard
signature.asc
Des
On 1/29/19 4:38 AM, Hal Murray via devel wrote:
> 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
Yo Hal!
On Tue, 29 Jan 2019 16:05:41 -0800
Hal Murray via devel wrote:
> 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
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.c
Yo James!
On Tue, 29 Jan 2019 15:23:04 -0800
James Browning via devel wrote:
> On 1/29/19, Gary E. Miller via devel wrote:
> > Yo Hal!
> >
> > On Tue, 29 Jan 2019 02:38:26 -0800
> > Hal Murray via devel wrote:
> >
> >> The complicated case is when we want to specify the IP Address.
> >> How
On 1/29/19, Gary E. Miller via devel wrote:
> Yo Hal!
>
> On Tue, 29 Jan 2019 02:38:26 -0800
> Hal Murray via devel wrote:
>
>> 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
>
Yo Hal!
On Tue, 29 Jan 2019 02:38:26 -0800
Hal Murray via devel wrote:
> 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
Why do we need ntp.example.com at all? Aren't we suppose
> 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
dev
Hal Murray via devel writes:
> 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'd suggest using a new keyword for that and leaving the existing ones
behijnd for NTP w/o encryption. In general you need to sp
Hal Murray via devel :
>
> 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
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 return
79 matches
Mail list logo
