Subject: Re: [Ntp] The NTP WG has placed draft-schiff-ntp-chronos in state "Call For Adoption By WG Issued"

From: Harlan Stenn <[email-masked]>
Date: Mon, 9 Sep 2019 21:50:18 -0700

While I support the intention and effort described by this document, I
am opposed to it being approved as an Informational document.  I would
support its approval as an Experimental document.

If sufficient documented research were to exist that clearly identified
better delineation of what precisely was and was not covered by this
research, and similarly identified any significant current-use cases
where additional studies needed to be made, there would be a roadmap of
what needed to happen before this became an Informational document.

On 8/27/2019 10:35 PM, IETF Secretariat wrote:
> 
> The NTP WG has placed draft-schiff-ntp-chronos in state
> Call For Adoption By WG Issued (entered by Karen O'Donoghue)
> 
> The document is available at
> https://datatracker.ietf.org/doc/draft-schiff-ntp-chronos/
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
> 

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Neta R S <[email-masked]>
Date: Tue, 10 Sep 2019 11:16:33 +0300

Hi Harlan,

Please see a brief description of Chronos threat model, Chronos algorithm
and security analysis below.

*Threat model: *Chronos considers a powerful form of man-in-the-middle
(MitM) Byzantine attacker, capable of determining precisely the values of
the time samples gathered by the Chronos client from
a subset of the NTP servers in its server pool (up to one-third of the
pool).

*A short reminder of Chronos' algorithm:*- Chronos client choose m servers
at random, queries them, orders their m samples according to their value,
drop the d lowest and highest samples.
- Then it tests the remaining set, and use its average as the new client's
clock only if the two conditions are satisfied:
1 - All the samples are close (up to 2w)
2 - Their average is close to the clients clock (up to ERR+2w)
Otherwise - the client resamples (choose again m servers at random, queries
them, orders them from low to high and drop the d lowest and the d highest
and tests the remaining set again).
After the client resamples (fails in the tests) K times, it moves to the
panic mode where all the servers are sampled.

*Security analysis*Chronos draft is based on the Chronos paper, which
provide a security analysis.
It was proved mathematically, that since Chronos use (slightly) more
servers to update, and choose them at random, the probability of successful
MitM attack decreases dramatically compares to NTPv4.
The improvement factor depends on the number of servers queries by Chronos
client at each update. For example, if the attacker controls 1/7 of the
servers in the pool, while querying 14 servers per update, Chronos client
can reduce its probability for timeshifthimg by a factor of approximately
1000.

Moreover, we considered the spectrum of feasible attack scenarios in order
to evaluate the
effectiveness of Chronos in thwarting timeshifting attacks.
The scenarios depend on how many malicious servers were queried.
We considered two scenarios:

*-  Scenario I: Less than m-d of the queried servers are under the
attacker’s control.*
It means, that there are more than d ''good'' samples (defined as up to w
away from the UTC).
In this scenario, there are two options:

1. There is at least one ''good'' sample in the remaining set, and then the
others should be close to it (according to condition 1, otherwise the
client resamples).
Then, the average of the samples in the remaining set (which is used to
update the client's clock) is close to the UTC.

2. There are no ''good'' samples in the remaining set. Thus, since there
are more than d ''good'' samples, the values of remain set are bounded by
''good'' samples.
Thus, the average of the remaining set is also close to the UTC

Therefore, these attack strategies are ineffective.

*- Scenario II:  More than m-d of the queried servers are under the
attacker’s control.*
In the worst case of this scenario, all the samples in the remaining set
are ''bad'' (more than w away from the UTC).
However, we proved in the paper that the probability of this scenario is
extremely low (since it requires malicious servers to be randomly chosen at
a much higher ratio than their ratio in the population – the pool).
Thus, the probability of repeated time shift is even exponentially lower –
negligible.
Consequently, a significant time shift is practically infeasible

Moreover, we examined the probability of DoS attack on the servers by an
attacker who cause many clients to resample and reach the panic mode
multiple times.
We found that the probability of this attack is extremely low, even if the
client moves to panic mode directly after 3 times of resampling.

*Next step:*We are continuing to evaluate Chronos's performance and
security for different attack strategies and at different locations.

Detailed discussions (along with the parameters evaluation can be seen in
the full paper:
https://www.ndss-symposium.org/wp-content/uploads/2018/02/ndss2018_02A-2_Deutsch_paper.pdf
)

Neta

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 10 Sep 2019 02:14:45 -0700

Hi Neta,

I want to see this sort of information either in the actual RFC or in
related RFCs, even for Informational documents.

I still have other issues with some of the core assumptions, and I'm not
currently able to elaborate on those now.

H

On 9/10/2019 1:16 AM, Neta R S wrote:
> Hi Harlan,
> 
> Please see a brief description of Chronos threat model, Chronos
> algorithm and security analysis below.
> 
> *_Threat model: 
> _*Chronos considers a powerful form of man-in-the-middle (MitM)
> Byzantine attacker, capable of determining precisely the values of the
> time samples gathered by the Chronos client from
> *_A short reminder of Chronos' algorithm:
> _*- Chronos client choose m servers at random, queries them, orders
> their m samples according to their value, drop the d lowest and highest
> samples.
> - Then it tests the remaining set, and use its average as the new
> client's clock only if the two conditions are satisfied:
> Otherwise - the client resamples (choose again m servers at random,
> queries them, orders them from low to high and drop the d lowest and the
> d highest and tests the remaining set again).
> *_Security analysis
> _*Chronos draft is based on the Chronos paper, which provide a security
> analysis.
> servers to update, and choose them at random, the probability of
> successful MitM attack decreases dramatically compares to NTPv4.
> The improvement factor depends on the number of servers queries by
> Chronos client at each update. For example, if the attacker controls 1/7
> of the servers in the pool, while querying 14 servers per update,
> Chronos client can reduce its probability for timeshifthimg by a factor
> of approximately 1000.
> 
> Moreover, we considered the spectrum of feasible attack scenarios in
> order to evaluate the
> _-  Scenario I: Less than m-d of the queried servers are under the
> attacker’s control._
> It means, that there are more than d ''good'' samples (defined as up to
> w away from the UTC).
> 1. There is at least one ''good'' sample in the remaining set, and then
> the others should be close to it (according to condition 1, otherwise
> the client resamples). 
> are more than d ''good'' samples, the values of remain set are bounded
> by ''good'' samples. 
> _- Scenario II:  More than m-d of the queried servers are under the
> attacker’s control._
> extremely low (since it requires malicious servers to be randomly chosen
> at a much higher ratio than their ratio in the population – the pool)..
> Thus, the probability of repeated time shift is even exponentially lower
> – negligible.
> We found that the probability of this attack is extremely low, even if
> the client moves to panic mode directly after 3 times of resampling.
> 
> *_Next step:
> _*We are continuing to evaluate Chronos's performance and security for
> different attack strategies and at different locations.
> 
> Detailed discussions (along with the parameters evaluation can be seen
> in the full paper:
> https://www.ndss-symposium.org/wp-content/uploads/2018/02/ndss2018_02A-2_Deutsch_paper.pdf)
> 
> 
> Neta
> 
> [email-masked]

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!

---

From: Neta R S <[email-masked]>
Date: Tue, 10 Sep 2019 12:53:58 +0300

Hi Harlan,

Please my comments inline.

> related RFCs, even for Informational documents.
We will consider the best way to present this information.

> currently able to elaborate on those now.
Sure, we are currently working on extending Chronos and we will be glad to
hear you thoughts.
I understand you can't elaborate now. It can be done after the adoption.

Neta