[Ntp] Antwort: Re: WGLC - draft-ietf-ntp-ntpv5-requirements

[[e-mail]]

Hey James, hey all,

let's get this last part out there (I'm noticing that I missed some stuff in the last mail regarding issues related to #2, but so be it, maybe I get to it later).

>> 4 Requirements

>> - "It should be able to provide enough information for both basic
>time information and synchronisation." We don't quite understand the
>implication with 'basic time information' - can you explain?
>
>"Basic time information" here is, for example a representation of
>UTC/TAI along with leap second information as opposed to extended
>timezone information, or historic leap seconds which are explicitly
>mentioned as non-requirements in a later section. This is an opening
>statement to set theme, and is not intended to be explicit in
>definition - the further subsections expand on what types of time
>information are to be part of the specification. Besides your
>question is there any specific further action here such as additional
>text, and if so could you propose something?

Since it is juxtaposed with synchronization: is the intent to use NTPv5 protocol messages for non-synchronization (e.g. just for asking "what time is it", or something)? That is where my confusion stems from.

If this is not the intent, then can we just take out the word 'both'?

No, I don't have concrete suggestions or need for changes here.

>> 4.1 Resource Management
>> - We feel this whole section runs counter to the subsequent one
>(Data Minimization); we feel that the requirements to support
>resource management (really, mostly rate limiting, some loop
>avoidance) are overly strong; we also feel like most of these
>features are prone to misuse/abuse and pose security risks. In
>conclusion, we would like to suggest lowering/rethinking the
>requirement levels.
>
>(#3a) (#3b?) I strongly disagree. Resource management is important
>for NTPv5 to address, particularly for large scale, public
>deployments - historically it's been a big enough problem it has its
>own Wikipedia page. There's been attempts to try and find a balance
>between resource management and data minimisation - one key example
>is the requirement to not use identifiers tied back to IP addresses
>or certificates, limiting certain on-path observers. Data
>minimisation is not just "remove all unnecessary data" but also
>having focused value for what data is required. What do you propose
>exactly?

It can be important to have strong anonymity in certain situations, where it can also be important to have good guarantees that someone is who they say they are (and is authorized to use a service). 

Both of these can be 'important' at the same time, yet it is still a fundamental problem in security that anonymity and authentication are often at odds in their realization - if I need to show my passport for something, it is just hard to stay anonymous.

I'm not saying to downplay any of the aspects (even though I personally think NTP's rate limiting and loop avoidance are somewhat anachronistic relics of the 80s and 90s)... but I am saying that in an informational RFC, I would really prefer there to be a sentence to the effect of:
"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"

(same for resource management and security, arguably also for data minimization and security), just so someone doesn't go in unprepared.

>> - Couldn't servers simply drop packets when over capacity, clients
>simply look for another server if theirs doesn't respond, or reduce
>their request rate? The logic would be much simpler, the security
>clearer.
>
>I disagree with this suggestion, as designed or implemented poorly
>would run the risk of DDoS, greatly impact the time for clients to
>synchronise amongst other potential issues. Dropped packets don't
>just happen when a server is congested, it can happen at any hop in
>the network when the link is congested. Explicit signalling is one of
>the ways attempting to prevent some of the challenges that have
>occurred in the past with unwanted traffic. How does your suggestion
>handle all possible scenarios of packets being dropped?

It doesn't. 

But how does the current suggestion handle all possible scenarios where someone is using rate limiting packets/messages to disrupt the flow of messages (one of the easiest form of DoS: false KoD packets)?

How does the current suggestion handle the case where a server is truly unavailable, to the point where it can't send an "I'm unavailable right now" message? Surely the clients can somehow deal with that scenario.

>> 4.2 Data Minimisation
>> - The term "optional data" needs to be clearly defined (and in my
>opinion discussed again).
>
>I'm not sure what needs to be specified here, as what is optional and
>required comes down largely to protocol design and what client and
>server need to fulfil higher level functional requirements. What
>exactly do you propose be specified here? Could you please suggest
>something?

If servers are going to do rate limiting, they need to know which client sent which packet.

Clients who do proper data minimization might not send any data in the packet that lets someone connect them to a previous packet (at least never in cleartext, so the very least an overworked server would have to do is decrypt state information).

So some measures you might take for data minimization will run counter to what you need for resource management.

>> - While we agree with the point made about data minimization, we
>feel that it runs counter to many other features/aspects (timescale,
>resource management, leap seconds, security).
>
>This is unclear to me what the issue is here - could you please be
>specific of what you think is contradictory?

See above.

Same thing for resource management vs. security (see further above).

Also, data minimization and security might be at odds; sure, you can just declare that anything security related is not 'optional' and thus data minimization might not apply - but realizing authenticity and integrity simply makes you send much more than the 'bare minimum' of data, and I think this can be pointed out.

>> 4.3 Algorithms
>> - The headline is confusing; the context with algorithm agility
>while not discussing crypto algorithms seems prone to
>misunderstandings. Perhaps change to "Time Processing Algorithms"?
>
>The opening sentence to the section I think makes clear that it's not
>specifying anything of cryptography. That being said this is a
>trivial change that could be included later if need be.

Sure. It also doesn't feel terribly important to me.

>> - The formulation "SHOULD be obvious" seems confusing.
>
>Could you please make a suggestion or advise on what to put instead.

I can't. I don't think I know what the text is expressing.

(Not a blocking issue, either. Let's ignore)

>> - The second paragraph seems to hint at specification-side
>modularity (on-wire protovol vs. processing algorithms vs. clock
>disciplining); while I like the idea, I believe it is controversial;
>I'm also unsure I'm even understanding the text correctly.
>
>Can you please describe in more detail what specifically you feel is
>unclear? The WG has discussed at length the need for being able to
>produce both UTC and TAI representations from the protocol; I was
>under the impression we had moved on from that discussion already.

This is about the second paragraph of 4.3 (Algorithms).

I simply thought having the document structure be modular (only specify on-wire, leave processing and clock disciplining for separate documents) would not be the clear WG consensus.

But you ought to know that better, and I'm happy if it is.

I don't want any changes in the text here (I just thought the rest of the WG might).

>> 4.8 Security
>> - If we shy away from naming a security option (e.g. NTS) as
>required for everyone, we leave the door open for a situation where
>two implementations can only do unsecured communication (because they
>support different, mutually exclusive security options).
>
>(#3c) I disagree. The document clearly states the protocol must have
>certain security capabilities - how it gets them is left up to
>protocol design. If it's NTS or something else I see that as somewhat
>orthogonal to this document and I'd like to leave the door open to
>future agility.
>
>> - We don't have a strong opinion on what's best, but if we require
>security to be supported, we must specify a minimal supported set.
>
>Could you please clarify what must be supported exactly? I don't
>believe this document should cover cryptography primitives, only
>capabilities which I believe are described at sufficient depth to
>permit protocol design.

I mean, your point stands that this could be left to the actual NTPv5 standards track RFC.

I still think you could write something to the effect of:

"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."

(You can leave open what that set is, but it would probably be good to note down that one is needed.)

>> - "Downgrading attacks that could lead to an adversary disabling or
>removing encryption or authentication MUST NOT be possible in the
>design of the protocol." is a difficult requirement. Under the
>problem outlined above, it might be simply unfulfillable. Also, it
>leaves unclear what is forbidden (only downgrading to zero security,
>or any downgrading at all)
>
>It's implied any downgrading - as an attack wouldn't just be
>weakening for the sake of it. Thieves don't cut only half the lock
>and leave it. I could adjust the text to directly state this.

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').

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.

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.

>> 5 Non-requirements
>> - This seems prone to misunderstanding: these are points that we as
>a WG have discussed and consented on not pursuing further; but it
>might sound like optional requirements?
>
>I'm not sure what is unclear here - those under the non-requirements
>are explicitly stated as out of scope, there is no text stating they
>are optional, and exist in the document to show that they have been
>considered as they were mentioned in previous discussion. Their
>inclusion in the document does not prevent them or other requirements
>not described being developed for NTPv5 in the future by the working
>group. Do you suggest this section be removed, or edited?

I guess it is just another example of where I expected the document to refer to WG consensus.

"The following are issues that the NTP working group discussed putting in the scope for NTPv5, but where it ultimately decided against doing so."

Not a blocking issue at all. 

(I also like having a section like this - there is an important difference between not mentioning something because we didn't think of it vs. saying we thought of this but deemed it not worth following up on. I would like it, as is, if the scope of the document were clear as reporting WG consensus in support of a future NTPv5 standards track RFC.)

>> 5.1 Server Malfeasance Detection
>> - I find it problematic to cite a draft (!) and claim that it
>"already provides this capability"; Roughtime is IMO not mature
>enough to do this
>
>Do you propose it be removed, or something else?

This is also a minor issue to me, but yeah, that minor issue is twofold: 

- I would like the reference to the Roughtime draft to be removed, for procedural reasons, just so we do not cite a non-finished document.

- I would like the claim that Roughtime already solves this softened 

Overall, I suggest something like:
"Detection and reporting of server malfeasance should remain out of scope, as there are other documents in development that aim at this capability as a core functionality of the protocol."

Besten Gruß / Kind regards, and see you all in less than 2 hours,
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]
__________________________________________