Re: [Ntp] I-D Action: draft-roughtime-aanchal-02.txt

[Watson Ladd <[e-mail]>]

On Wed, May 29, 2019, 6:29 AM Tal Mizrahi <[e-mail]> wrote:

> Dear authors,
>
> Thanks for updating the draft. The new text in the Introduction is highly
> appreciated, and addresses some of the concerns I raised.
>
> Comments:
> 1. The document is still missing a threat analysis. There should probably
> be a dedicated section that describes the threats that are and are not
> solved by Roughtime.
> 2. In IETF 104 the authors and Kristof explained that delay attacks are
> mitigated by measuring the RTT and comparing it to a pre-configured upper
> bound. This should be described in the draft.
>

That converts a delay attack into no measurement. But one still learns a
bound that is valid, just not very confining.  There is no MLE estimator
necessarily, so delays might not induce systemic errors. Some applications
are of this form.

3. The draft should discuss upper bounds on how "bad" a server can be
> without being detected as a falseticker.
>
> Some proposed text follows.
>
> Cheers,
> Tal.
>
>
> Here is some (preliminary) proposed text for (2) above:
>
> Although delay attacks cannot be prevented, they can be limited to a
> predetermined upper bound. This can be done by defining a maximal tolerable
> RTT value, MAX-RTT, that a client is willing to accept. A Roughtime client
> can measure the RTT of every request-response handshake and compare it to
> MAX-RTT; if the RTT exceeds MAX-RTT, the corresponding server is assumed to
> be a falseticker. When this approach is used the maximal time error that
> can be caused by a delay attack is MAX-RTT/2. It should be noted that this
> approach assumes that the nature of the system is known to the client,
> including reasonable upper bounds on the RTT value.
>
>
> Here is a preliminary proposal for some text for (3) above (needs to be
> reviewed and discussed):
>
> As discussed in the introduction, the absence of proof of malfeasance does
> not indicate that all the servers are "good". However, if the Roughtime
> mechanism indicates that all servers are well-behaved then Roughtime
> timestamps can be used to compute an upper bound on the time error of a
> potential falseticker. For example, for a given set of responses (r_1, r_2,
> r_3) from three servers, if it is guaranteed that server 1 and server 3 are
> truechimers, then the client has an upper bound on the time error that may
> be caused by the reply from server 2, as the timestamp of server 2 is
> bounded by the timestamps of server 1 and server 3. Thus, the time error
> from server 2 cannot exceed:
>
> max{MIDP_3 - MIDP_2 + RADI_3 + RADI_2,
>     MIDP_2 - MIDP_1 + RADI_2 + RADI_1}.
>
> More generally, if n servers are used in the protocol, and for a given set
> of responses (r_1, r_2, ..., r_n, r_1'), if server 1 is guaranteed to be a
> truechimer, then the time error that may be caused by each of the servers
> 2, 3, ..., n is bounded by:
>
> MIDP_1' - MIDP_1 + 2*RADI_1
>

This does not seem quite right: the error in the timestamp is bounded
(which is explained in definition of a falseticker: perhaps that needs to
be relabled). The error induced in the time is a very different beast.
Thanks for the suggested text.


>
> On Mon, May 27, 2019 at 8:03 PM <[e-mail]> wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Network Time Protocol WG of the IETF.
>>
>>         Title           : Roughtime
>>         Authors         : Aanchal Malhotra
>>                           Adam Langley
>>                           Watson Ladd
>>         Filename        : draft-roughtime-aanchal-02.txt
>>         Pages           : 11
>>         Date            : 2019-05-27
>>
>> Abstract:
>>    This document specifies Roughtime - a protocol that aims to achieve
>>    rough time synchronization while detecting servers that provide
>>    inaccurate time and providing cryptographic proof of their
>>    malfeasance.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-roughtime-aanchal/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-roughtime-aanchal-02
>> https://datatracker.ietf.org/doc/html/draft-roughtime-aanchal-02
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-roughtime-aanchal-02
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> ntp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ntp
>>
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp
>