[Ntp] Antwort: Re: [NTP] Roughtime: Inadequate Explanation of Protocol's Unique Feature? (Question to all WG members)

[[e-mail]]

@ntp-wg: please largely ignore the dive into detail below, and instead go to the opinion I asked elsewhere if you want to help :)

@watson:

You're welcome, and thanks for engaging with the feedback so openly.

Section 4 could use an editing pass IMO, especially in the first 1-2 sentences: I cannot parse exactly which timestamp t_1, t_2, t_3 goes with which packet (but there are multiple options that make sense, so it's fine overall).

But even when I fill in some blanks, I have to really stretch to read from Section 4 anything that pertains to the chaining mechanism (which I again have to fill out some blanks but I think I can imagine what you mean).

Section 9.2 is more clearly related, but it seems to be swallowing some pretty helpful information:

- Why these bursts of 3 queries? Wouldn't it be more obvious to keep the sequence (chain?) running, i.e. use the third response instead of some NONC on a subsequent query (and thereby have another chain of 3 with different pairing)? 

- (related:) If I'm sticking to 3 queries, won't I be limited to catching the culprit for inconsistencies ONLY if it is the "middle" server that I queried

(i.e. if the time from the 1st is too early, or that of the 3rd is too late, there won't be a violation of ordering in my chain, right?)

(also, if there is a clash between the 1st and 2nd, but neither clashes with the 3rd, I will have a hint of malfeasance, but no clear suspect, right?) 

- Isn't the whole concept of detecting inconsistencies through looking for violation of ordering also highly dependent on the frequency with which I query? There needs to be overlap for crypto proof, so if I only query e.g. every 10 seconds, I will not necessarily be able to prove a 9 second error/inconsistency/deception... right?

- Wouldn't a burst of 2 queries then be similarly useful? I could only detect 

I don't know... it bothers me a bit to think that for all of this, I need to fill in so many blanks to even come up with these questions; and that what's in the draft doesn't seem to let me find a clear answer for either of them.

I guess I advocate for maybe one simple example to get the point across.

If we had one, maybe that would also be the point to interject with a quick "And thus, cryptographic proof of inconsistencies SHOULD be sent in for review by a group of human judges", if that's what you advocate for (I really think it would be much neater if there could be more algorithmic preparation, such as clearly identifying 2 servers that seemed consistent and one that clashed with both of them, but this is highly subjective).

...and all of this is before we even go into possible consequences of detecting malfeasance and clearly identifying a culprit. 

Your point about not being too prescriptive in advance is taken, I guess.

But someone somewhere needs to do the prescribing at some point. 

And being underly prescriptive carries its own risks.

Besten Gruß / Kind regards,
Kristof Teichel

__________________________________________

Dr.-Ing. Kurt Kristof Teichel
Physikalisch-Technische Bundesanstalt (PTB)
Arbeitsgruppe 4.42 "Zeitübertragung"
Bundesallee 100
38116 Braunschweig (Germany)
Tel.: [phone]
E-Mail: [e-mail]
__________________________________________

-----"Watson Ladd" <[e-mail]> schrieb: -----

An: [e-mail]
Von: "Watson Ladd" <[e-mail]>
Datum: 03.09.2024 18:03
Kopie: "NTP WG" <[e-mail]>, "Marcus Dansarie" <[e-mail]>
Betreff: [Ntp] Re: [NTP] Roughtime: Inadequate Explanation of Protocol's Unique Feature? (Question to all WG members)

On Tue, Sep 3, 2024 at 1:37 AM <[e-mail]> wrote:
>
> @watson/ben: thanks for your replies
> Can the information about the ecosystem and reporting system be found anywhere else?
> Not necessarily about a server list or who runs them, but about how the logic works, how reporting should roughly be done, etc.?

First let me say I very much appreciate the effort you are spending on
improving the draft. It's very easy for me as author to think I have
explained things well when I have not. I think what I have in the
draft is there but is fairly telegraphic. A client queries multiple
servers, and through the chaining mechanism can determine if they give
inconsistent results (Section 4 and 9.2). When there is an
inconsistency the client reports, and we have a format for doing that
(might need more explication). When the client reports, and what
happens after is currently beyond scope.

I'm not sure what logic you are discussing. We certainly can put in
more examples and explanations of how having three causally related
measurements can impeach a server giving the incorrect time.
Ultimately though distrust comes about through human understanding of
which one was wrong.

> (If so, could you link to that?)
> Or are you saying it's okay for this to not be documented anywhere?

Part of the problem is that we do not have any such program operating
to describe, and being very prescriptive about things that don't yet
exist is a losing battle.

>
> Let's remember that this is Roughtime's supposed core technical feature.

I think roughtime has this feature and it's just a matter of
documentation. But we can't dictate the human bits come into
existence: they either will or will not, and will operate according to
their needs. Mozilla has a very different root program than Apple.

Sincerely,
Watson Ladd

>
> @ntp-wg: I was really looking for input on this from people who didn't have an active role in developing Roughtime.
> I ask you all again to provide a short opinion, please.

Yes, please chime in!

>
>
> Besten Gruß / Kind regards,
> Kristof Teichel
> (and Martin Langer)



--
Astra mortemque praestare gradatim

_______________________________________________
ntp mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]