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

From: [email-masked]
Date: Mon, 27 May 2019 10:03:41 -0700

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/

---

From: Thomas Peterson <[email-masked]>
Date: Tue, 28 May 2019 16:01:19 +0100

Thank you for publishing a new version of the draft.

Some feedback based on your new changes, the existing concerns raised 
prior not withstanding:

* Nit: "... violations are greater then a second the loss..." should be 
"greater than a second"
* You have not provided sufficient information for implementations on 
how to actually calculate time, only citing a single, out-of-publication 
reference. Besides Wikipedia and a humor page[0] stored on the Internet 
Archive, I have been unable to find a definitive source that describes 
MJD. Could you please in a future version describe in detail how an 
implementation take the time received and perform the necessary 
computation to something that could be applied to a system clock.
* Would it not be more appropriate to break up the MIDP value so the MJD 
day and time offset from midnight be pout into separate keys?
* Is there a specific reason why the document has now a mixture of "bit" 
and "byte"? For example, MIDP is 8 _bytes_, but RADI is 32 _bits_. It's 
reasonable to assume that a reader can distinguish, but having a mixture 
such as this could lead to errors in implementations due to reader error.

Regards

0: 
https://web.archive.org/web/20070606064704/http://vms.tuwien.ac.at/info/humour/vms-base-time-origin.txt

On 27/05/2019 17:03, [email-masked] wrote:
> 1
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 29 May 2019 10:23:50 +0200

>>> Thomas Peterson <[email-masked]> schrieb am 28.05.2019 um 17:01
in
Nachricht <[email-masked]>:
> how to actually calculate time, only citing a single, out‑of‑publication 

RFC 1305 refers to it, too: "The Modified Julian Date (MJD), which is
sometimes used to represent dates near
our own era in conventional time and with fewer digits, is defined as MJD = JD
– 2,400,000.5.
Following the convention that our century began at 0h on 1 January 1900, at
which time the tropical
year was already 12h old, that eclectic instant corresponds to MJD 15,020.0.
Thus, the Julian
timescale ticks in standard (atomic) 365.25-day centuries and was set to a
given value at the
approximate epoch of a cosmic event which apparently synchronized the entire
human community,
the origin of the Common Era."

Later: "The UTC timescale thus ticks in standard (atomic) seconds and was set
to the value 0h MJD 41,317.0
at the epoch determined by astronomical observation to be 0h on 1 January 1972
according to the
Gregorian calendar; that is, the inaugural tick of the UTC Era."

"The NTP timescale is based on the UTC timescale, but not necessarily always
coincident with it.
At 0h on 1 January 1972 (MJD 41,317.0), the first tick of the UTC Era, the NTP
clock was set to
2,272,060,800, representing the number of standard seconds since 0h on 1
January 1900 (MJD
15,020.0)."

Finally in RFC 6055 ;-)
   [MJD]            Duerst, M., "The Properties and Promizes of UTF-8",

Regards,
Ulrich Windl

> https://web.archive.org/web/20070606064704/http://vms.tuwien.ac.at/info/humo

> ur/vms‑base‑time‑origin.txt
> 
> On 27/05/2019 17:03, internet‑[email-masked] wrote:
>> 
>> A New Internet‑Draft is available from the on‑line Internet‑Drafts
directories.
>> 	Filename        : draft‑roughtime‑aanchal‑02.txt
>> 	Pages           : 11
>> 	Date            : 2019‑05‑27
>> 
>> Abstract:
>>     This document specifies Roughtime ‑ a protocol that aims to achieve
>> https://datatracker.ietf.org/doc/draft‑roughtime‑aanchal/ 
>> 
>> https://tools.ietf.org/html/draft‑roughtime‑aanchal‑02 
>> https://datatracker.ietf.org/doc/html/draft‑roughtime‑aanchal‑02 
>> 
>> https://www.ietf.org/rfcdiff?url2=draft‑roughtime‑aanchal‑02 
>> 
>> 
>> Internet‑Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet‑drafts/ 
>>

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 29 May 2019 16:28:51 +0300

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

---

From: Watson Ladd <[email-masked]>
Date: Wed, 29 May 2019 08:55:13 -0700

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

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

---

From: Thomas Peterson <[email-masked]>
Date: Wed, 29 May 2019 20:07:02 +0100

Thank you for finding those references. I have raised a pull request[0] 
with an attempt to initially describe the details I believe the draft 
should have in place. Feedback from yourself and the mailing list would 
be appreciated.

However, the reference you cited from RFC 6055 is slides and notes from 
a presentation going into UTF-8[1], and appears to have nothing to do 
with time.

Regards

0: https://github.com/aanchal4/draft-roughtime/pull/14
1: 
https://web.archive.org/web/20060603174545/www.ifi.unizh.ch/mml/mduerst/papers/PDF/IUC11-UTF-8.pdf