Yo Eric!
On Mon, 14 Jan 2019 22:26:54 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > > Why are you fighting so hard for the reuse case?
> >
> > Because the Proposed RFC allows for it, so some will use it. We
> > need to be interroperable. It may be useful for bad connection
Gary E. Miller via devel :
> > Why are you fighting so hard for the reuse case?
>
> Because the Proposed RFC allows for it, so some will use it. We need to
> be interroperable. It may be useful for bad connections.
While I concded your point that we need to plan for interoperability, Gary,
I'm
Hal Murray :
>
> > Good to know. Yeah, NTP at that volume is sure not going to saturate even a
> > smartphone, let alone anything you'd put in a desktop or server case.
>
> I can get 20k pkt/s through a Pi 3.
So, to a reasonable first approximation, a RasPi 3 could handle PTB's
load with 50% h
> Good to know. Yeah, NTP at that volume is sure not going to saturate even a
> smartphone, let alone anything you'd put in a desktop or server case.
I can get 20k pkt/s through a Pi 3.
There is an interesting quirk in this area. Suppose you have a traffic
generator with a knob on it, and y
Yo Hal!
On Mon, 14 Jan 2019 14:19:00 -0800
Hal Murray via devel wrote:
> > Seems to me that reuse is in the spirit of the draft. And not a
> > corner case, a very simple basic case. The sort of thing a minimal
> > client would do.
>
> It's a corner case in the sense that half the document w
Achim Gratz via devel :
> Answer from PTB: Current packet rate is still lower than 10k/s peak over
> all three servers. Not sure how well balanced that is, but I guess it's
> safe to say that it's less than 5k/s on each server.
Good to know. Yeah, NTP at that volume is sure not going to saturate
> Seems to me that reuse is in the spirit of the draft. And not a corner case,
> a very simple basic case. The sort of thing a minimal client would do.
It's a corner case in the sense that half the document wouldn't be needed if
the designers thought that was normal.
We aren't dealing with a
Yo Hal!
On Mon, 14 Jan 2019 13:30:03 -0800
Hal Murray wrote:
> Gary said:
> > One is sufficient for that. Cookie reuse is fine.
>
> Cookie reuse is fine in the sense that it should work. But the whole
> tone of the draft is that they won't be reused. There is only a
> minor note that says
> While I don't know what the rationale was for the RFC, it still makes sense
> to provide a client with enough cookies so it can fire off the initial burst
> w/o re-keying even if all responses get lost.
The NTS-KE section has a SHOULD return 8 keys, but only 1 is required.
--
These are my
Gary said:
> One is sufficient for that. Cookie reuse is fine.
Cookie reuse is fine in the sense that it should work. But the whole tone of
the draft is that they won't be reused. There is only a minor note that says
you can reuse them.
I think we should follow the spirit of the draft rath
Yo James!
On Mon, 14 Jan 2019 13:01:27 -0800
James Browning via devel wrote:
> > > When the NTP server is returning new cookies to the client, they
> > > are encrypted so that a spy can't track the client if it moves to
> > > a new IP Address before it uses the cookie.
> >
> > I see nothing in
Yo Hal!
On Mon, 14 Jan 2019 12:58:00 -0800
Hal Murray via devel wrote:
> > Why would a client waste all is cookies at once? Since they can be
> > reused until the NTPD returns a NACK this seems to ddefeat the
> > benefit of keeping spare cookies around.
>
> To avoid bad-guys tracking you wh
On Mon, Jan 14, 2019, 12:30 PM Gary E. Miller via devel Yo Hal!
>
> On Mon, 14 Jan 2019 12:19:09 -0800
> Hal Murray via devel wrote:
>
> > When the NTP server is returning new cookies to the client, they are
> > encrypted so that a spy can't track the client if it moves to a new
> > IP Address be
Yo Achim!
On Mon, 14 Jan 2019 21:54:03 +0100
Achim Gratz via devel wrote:
> Hal Murray via devel writes:
> >> BTW, the number eight is not arbitrary: that is exactly the number
> >> of packets a burst poll would use.
> >
> > The normal case is that the client gets back a response before it
>
> Why would a client waste all is cookies at once? Since they can be reused
> until the NTPD returns a NACK this seems to ddefeat the benefit of keeping
> spare cookies around.
To avoid bad-guys tracking you when you change IP Addresses.
The NTP client gets a new cookie with each response. I
Yo Hal!
On Mon, 14 Jan 2019 12:45:58 -0800
Hal Murray via devel wrote:
> > It is actually allowed to re-use cookies, specifically if it wants
> > to avoid that re-keying. Whether that's a good idea is debatable,
> > but the server doesn't know either way and the decision is up to
> > the client
Hal Murray via devel writes:
>> BTW, the number eight is not arbitrary: that is exactly the number of packets
>> a burst poll would use.
>
> The normal case is that the client gets back a response before it sends the
> next request in the burst, so it only needs 1 cookie to start with.
While I d
> It is actually allowed to re-use cookies, specifically if it wants to avoid
> that re-keying. Whether that's a good idea is debatable, but the server
> doesn't know either way and the decision is up to the client.
Right.
I think we should make a "no reuse" decision. We want that option for
Yo Achim!
On Mon, 14 Jan 2019 21:32:29 +0100
Achim Gratz via devel wrote:
> BTW, the number eight is not arbitrary: that is exactly the number of
> packets a burst poll would use.
Why would a client waste all is cookies at once? Since they can be
reused until the NTPD returns a NACK this seems
Hal Murray via devel writes:
> The client starts with 8 cookies. If a packet gets lost, the next request
> includes a single cookie-please slot. The server returns an extra cookie so
> the client is back to 8. The cookie-please slot has the same length as a
> cookie slot so you can't use cook
Yo Hal!
On Mon, 14 Jan 2019 12:19:09 -0800
Hal Murray via devel wrote:
> When the NTP server is returning new cookies to the client, they are
> encrypted so that a spy can't track the client if it moves to a new
> IP Address before it uses the cookie.
I see nothing in the Proposed RFC that bind
Hal Murray via devel writes:
>> Not only, any data in encrypted extension fields that goes back to the server
>> is encrypted with the c2s key (from the P portion of the paylod in section
>> 5.6 of the RFC).
>
> The cyphertext of figure 4 contains both the encrypted version of any headers
> we wan
> Not only, any data in encrypted extension fields that goes back to the server
> is encrypted with the c2s key (from the P portion of the paylod in section
> 5.6 of the RFC).
The cyphertext of figure 4 contains both the encrypted version of any headers
we want to encrypt and the authentication
Achim Gratz via devel writes:
> Eric S. Raymond via devel writes:
>> Achim Gratz via devel :
>>> I could try to contact the responsible person for NTP at PTB if you
>>> can't get at information from NIST.
>>
>> Probably a good idea to have PTB figures even if we *can* get some from NIST.
[…]
> By t
Yo Hal!
On Mon, 14 Jan 2019 03:50:49 -0800
Hal Murray via devel wrote:
> You said "encrypts the rest of the data"
> I think we are authenticating rather than encrypting.
Check out the definition of AEAD. It is an encrypt, then hash, function.
So you get both. Plus the option of some unencrypt
Hal Murray via devel writes:
> You said "encrypts the rest of the data"
> I think we are authenticating rather than encrypting.
Not only, any data in encrypted extension fields that goes back to the
server is encrypted with the c2s key (from the P portion of the paylod
in section 5.6 of the RFC).
Udo van den Heuvel via devel :
> On 14-01-19 08:14, Mark Atwood via devel wrote:
> > NTPsec 1.1.3 has been released.
> > https://blog.ntpsec.org/2019/01/13/version-1.1.3.html
>
> Thanks.
>
> The pic directory in the source tree holds the panda.adoc file that
> should be located one level higher
On 14-01-19 08:14, Mark Atwood via devel wrote:
> NTPsec 1.1.3 has been released.
> https://blog.ntpsec.org/2019/01/13/version-1.1.3.html
Thanks.
The pic directory in the source tree holds the panda.adoc file that
should be located one level higher I guess.
Kind regards,
Udo
_
I've started adding references to the draft.
Ian: I didn't touch your recent edits.
You said "encrypts the rest of the data"
I think we are authenticating rather than encrypting.
The new cookies returned from the NTP server are encrypted. I think that's at
a different
layer. The AEAD stuff
29 matches
Mail list logo
