[Ntp] Antwort: Re: Making summary comment Kristof

[[e-mail]]

Hey all,

I finally took the time to review the changes against my list of comments.

Everything that I marked as blocking has been resolved - occasionally with the minimum solution, but that's still a solution :)

So let's start off with the good news: I don't have any hard reservations against advancing the document anymore.

The only issues remaining are non-blocking stuff.

Two of those area  bit dear to me (even if I stand by them being non-blocking).

a) The mention of Roughtime in 5.1 (specifically as a normative reference) irks me. 

I'm not sure that Roughtime really does what is described sufficiently well for this text to be final. 

I also formally don't like that a draft is cited as a normative reference at all.

b) My offer still stand that Martin and I could suggest a re-write of Section 3. 

It summarizes RFC7384 at least for the distinction into attack types, but I'm really unsure about the text under 3.1-3.3 - I'm not convinced it is in line with RFC7384 , or that I agree with it.

(I didn't put this as an actionable item because it seemed hard to make a concise suggestion other than 'maybe re-write this'.)

Maybe we can get some input from the group on these? Otherwise I will just let them go.

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]
__________________________________________

-----"James" <[e-mail]> schrieb: -----

An: [e-mail]
Von: "James" <[e-mail]>
Datum: 08.01.2024 17:16
Kopie: "David Venhoek" <[e-mail]>
Betreff: Re: Making summary comment Kristof

David,

Thanks once again for doing this work. I'd like to just address the blocking issues first, and come back to the non-blocking later, time permitting.

Points raised for Kristof are inline. I've updated the copy on Github, and would prefer to avoid publishing a new version until we clear more of these points.

> On 17 Dec 2023, at 12:42, David Venhoek <[e-mail]> wrote:
>
> Dear James, Kristof,
>
> Below a summary of Kristof's emails AFTER his first set of comments.
> This focuses primarily on the actionable issues. There is one point
> where I have added a little bit of James reply in the mix just to make
> this more clear, but for the rest it should all only reflect Kristof's
> text. In a number of places I have copied directly from his original
> emails, those are marked by text in  <<>>.  Apologies in advance for
> the spelling and grammar mistakes, hope they aren't to distracting but
> just don't have the time to go over my own mail another time right
> now.
>
> Kristof, I have the following specific questions left for you:
>
> There were a number of comments around data minimization and resource
> management that felt like they were more aimed already at the
> discussions for how to actually do this, rather than what we want on
> this front. I have left these out of the summary here if that is ok
> with you?
> Also, I have moved #2d to non-blocking due to your comments on the
> previous consensus calls, please correct me if that is not what you
> intended. I can also send the explanation I gave during the meeting in
> a mail on the list if you would prefer to have that part more
> documented?
> Other than that, can you quickly check the summary to see if I missed
> any points and if everything is classified correctly?
>
> Also, feel free to repost this summary to the general mailing list if
> you think it is useful for others to also have access to, Kristof.
>
> Hope it will be useful.
>
> Kind regards,
> David Venhoek
>
> Summary
> =======
>
> Blocking issues:
> ----------------
>
> #1 Lack of clarity from the document on it's role in the process.
>  - Does it regulate the spec (the document), the implementations (the
> code), the userbase, or something else
>  - Short statement stating which it is could go a long way.

I've added some text which should address this in the abstract.

> #2a Use cases:
> - Missing overal description, something along lines of "NTP used to
> sync large amounts of computers via open (internet-like) networks"

Text has been added which should address this.

> - Potential to misread, especially around comments towards PTP and
> being diminutive towards NTP.
> Causes misread (quote):
> <<"used to synchronise devices such as customer-premises equipment
> where reduced accuracy may be tolerable" (Reduced relative to what?
> Sounded like 'better protocols' such as PTP to me... did you mean the
> 'publicly accessible NTP services' from earlier?)
> "NTP services both for internal use and for customers, particularly
> where the network is unable to offer or does not require other
> protocols e.g. PTP" (primary example of where it feels almost
> diminutive to NTP - I get now that this is probably still meant in the
> specific context of data centers, where that perspective is a lot more
> valid)
> "and where there may already be familiarity with NTP" (makes it feel
> IMO like NTP is definitely not the default, but same as above)>
> Suggestion:
> - Different start to set different tone?
> - More focus towards NTP is norm
> Text suggestion:
> <<"If someone is trying to keep the clock in their computing device
> synchronized, then they are likely using NTP for it. As such, NTP has
> billions of users and is used on even more devices.">>
> Then go into specific use cases after.

I've made some minor adjustments to text, and regret ever mentioning PTP.

> #2b Threat analysis
> - RFC7384 reference rather than copy and summarize here

RFC 7384 is referenced and what text is there aims to highlight and expand upon specific threats and complement section 3 with additional information, for example the suggestion to design with the considerations made in RFC 8085, a document published several years after RFC 7384. No text has been copied verbatim and I don't believe any text poses an ambiguity risk.

> #2c Timescales
>    - Missing clarity that UTC is not ok as linear, monotonic timescale

I've added text that should address this.

> #3a Tensions in requirements
> - Tension between requirements on resource management, data minimization
> - Tension between requirements on resource management, security
> proposed solution: something like <<"Realizing data minimization and
> resource management at the same time might be difficult, as the ends
> used to achieve them tend to work against each other">> and similar
> for the other conflicts.

I've added some text in the data minimisation section.

> #3b Security, tension between upgradeability and ruling out downgrade
> attacks. Quote:
> <<
> Maybe I'm just being dense, but I don't see how one can possibly allow
> upgrading but also completely prevent downgrading (at least to the
> specified 'baseline').

The same way other protocols negotiate security primitives - in handshake specify what is supported/accepted and will be used, and use later versions of protocols, IANA registry updates, and RFC/BCPs to indicate what is deprecated and recommended for use in future. For NTPv5 it's likely NTS and its dependant protocols will deal with that.

> Perhaps this is another issue where I don't understand if the document
> is intending to regulate the NTPv5 standards track RFC, or
> implementations, or something else.

The intent is stated in the abstract, and has been further clarified based on other comments made. To be clear it's informing protocol specification (and recommending actions for the working group to a lessor extent) knowing what is developed will infer onto implementations and deployments.

> I would really like to understand this, as it seems like a blocking
> issue with my current degree of (non-)understanding of it.
> Currently, I'm afraid someone will sit there and be unable to check
> all MUST requirements as fulfilled, because it might be impossible to
> fulfill all at the same time.

Given that the current protocol specification is going down the path of using NTS, if there is a specific concern in normative language you feel is in contradiction with that, please let me know.

> #3c Require a single security mechanism to be supported by all clients.
>    - Suggestion: <<"The specification MUST settle on a defined set of
> supported security schemes so that it is guaranteed that any two
> implementations have a way to established secured exchanges.">>

I've added text that addresses this.

> Non-blocking issues:
> --------------------
>
> Use of normative language is inconsistent.
> Reply (james):
> - Use of normative vs non-normative is intentional. Let's not remove
> all or make all normative
> - Use of SHOULD is intentional, reflects potential for circumstances
> Re-reply (kristof):
> - Perhaps replace non-normative should with ought or similar so as
> not to cause confusion.
> - Non-capitalized must also occur, are those really intentional?
>
> Confusion about requirements applying to protocol implementation:
> Perhaps somewhat pedantic, but examples:
> 4.1 "Clients SHOULD periodically re-establish connections with servers"
> "Servers SHOULD be able to migrate and change  any identifier used"
> 4.6 "Servers that support multiple versions of NTP MUST send a
> response in  the same version as the request"

> Algorithm separation text seems an allusion to working group actions,
> suggest doing this through an explicit statement of scope. Quote: <<If
> we can agree to add a sentence earlier to the effect of 'this document
> is supposed to be an orientation for how the upcoming NTPv5 standards
> track RFC is to be written', then we can for the current point just
> add one line
> "The NTPv5 RFC should/SHOULD cover the on-wire protocol only;
> processing algorithms and clock disciplining techniques can be covered
> in separate documents.">>
>
> Section use cases: Some of the text appears to be setting up things
> that are never referenced in the document again. Examples:
>    - different kinds of ntp servers
>    - kinds of deployments
>
> Section leap seconds: 24 hours before explanation is clunky, add one
> sentence clarification?
> suggestion: <<"The specification MUST require that servers transmit
> upcoming leap seconds greater than 24 hours in linear timescale in
> advance if known in time, otherwise as soon as possible.">>
>
> #2d Leap seconds
> - Disagree with statement around leap smearing SHOULD be supported and
> MUST be dealt with. Potential issue with clients having to
> indefinitely carrying support.
> - Is the result of concensus call, so maybe not reopen
>
> Requirements section:
>    - Some confusion around "basic time information"
>    - Source: unclarity about intent to sue NTPv5 protocol for
> non-synchronization <<(e.g. just for asking "what time is it", or
> something)>>
>    - If not above, maybe remove the 'both' just before "basic time
> information".
>    - No concrete suggestions or need for changes
>
> Non-requirements section seems prone to misunderstanding:
>  - Would expect the document to refer to WG consensus
>  - Like having the section though.
>