Subject: [Ntp] Roughtime draft

From: Aanchal Malhotra <[email-masked]>
Date: Fri, 8 Feb 2019 14:11:58 -0800

Hi All,

We have put together a draft for Roughtime. We encourage folks here to have
a look at the draft and see if they think that there is a value in
adopting/implementing it and would be interested to do so.

 https://tools.ietf.org/html/draft-roughtime-aanchal-00

Best,
Aanchal.

---

From: Daniel Franke <[email-masked]>
Date: Fri, 8 Feb 2019 17:48:14 -0500

I think we can do better than to send smeared time on the wire. Let
timestamps be TAI-based, and let each response contain, in addition to
the timestamp, the most-recently-published leap second (which could be
in the past or could be in the future). Data for a leap second
consists of a sequence number, a bit indicating whether it is an
insertion or a deletion, the TAI time at which the leap second ends,
and what the TAI-UTC offset will be after the leap second has elapsed.
Also provide separate message types for querying and communicating
historical leap seconds.

This will allow clients to decide as a matter of policy how and
whether to smear, rather than baking the decision into protocol
mechanism. Furthermore, it creates a malfeasance-evident mechanism for
distribution of leap second data, thus filling what is presently a
void.

On Fri, Feb 8, 2019 at 5:12 PM Aanchal Malhotra <[email-masked]> wrote:
>
> Hi All,
>
> We have put together a draft for Roughtime. We encourage folks here to have a look at the draft and see if they think that there is a value in adopting/implementing it and would be interested to do so.
>
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: "Gary E. Miller" <[email-masked]>
Date: Fri, 8 Feb 2019 15:28:53 -0800

Yo Daniel!

On Fri, 8 Feb 2019 17:48:14 -0500
Daniel Franke <[email-masked]> wrote:

> in the past or could be in the future).

+1.  

Having NTP serve smeared time has already caused big problems.

Confine that mess to the client.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	[email-masked]  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

---

From: Marcus Dansarie <[email-masked]>
Date: Sun, 10 Feb 2019 22:07:26 +0100

Hi!

I've heard about Roughtime before and have had it described to me, but
this is the first time I have actually read a specification. After
reading through the draft, I made a quick client implementation in
Python which is available on Github: https://github.com/dansarie/pyroughtime

Here's a couple of comments and suggestions based on my first impressions:

First of all, I like how simple and straightforward the protocol is. It
should be possible to implement even on small platforms. I also note
that it is possible to create a very small client implementation
entirely without any cryptographic functions. (Though it's not a good
idea to do so other than in very special circumstances.) The
amortization of the signatures over a (possibly) large number of
requests is a nice idea.

In Section 1, the draft says that "newer protocols like [NTS] fail to
ensure that the servers behave correctly." This is technically true,
because it is not a design goal of NTS. When using NTS, server
misbehavior is detected by the same means as in standard NTP. All but
the simplest NTP implementations have the capability to detect rogue
time servers and Chronos represents the state-of-the-art in doing so.
That said, I don't dispute the motivation or need for Roughtime.

A couple of nits in Section 3:
* "The response inculdes" should be "The response includes"
* "used to indicate the servers certainty" should be "used to indicate
the server's certainty"
* "response so that its needed to" should be "response so that it's
needed to"
* "proof of any servers misbehavior" should be "proof of any server's
misbehavior"

The abbreviations uint32 and uint64 are used a number of times without
explanation. While their meanings should be obvious to any experienced
programmer, they should be explained. "Unsigned 32-bit integer in
little-endian format" should suffice.

The message format was a bit confusing at first. A figure in Section 4
would have made the text easier to understand.

While Section 4 is very clear on how uint32s are converted to and from
byte strings, the same is not true for longer byte strings. I was a bit
confused about how to parse longer fields, such as public keys and
signatures, and about how pass the signed tags to the verification function.

Section 4 contains the phrase "Exempli gratia". Please change this to
"For example," to improve readability.

Section 5.1 states that request packets must be at least 1024 bytes. I
assume the reason for this requirement is to prevent amplification
attacks. If so, this should be stated explicitly in either section 5.1
or in the security considerations. Also, there should be a requirement
that servers MUST ignore request packets that are shorter than 1024 bytes.

The PAD tag key is encoded as PAD\xff, while the SIG tag key is encoded
as SIG\x00. For consistency, this should be changed so that both are
terminated with \x00. Additionally, terminating the tag keys with the
NULL character will make displaying them easier on many platforms.

Section 5.2 is hard to read. My suggestion is to give each tag its own
subsection. For example, the one on SREP could read:
"SREP is a parent tag in Roughtime format. It contains the ROOT, MIDP,
and RADI tags."

Nit: The first sentence in Section 5.2 is comma spliced.

In Section 5.2.1, the text "a Merkle tree using SHA512 as described when
we reach the PATH and INDX blocks" should be changed to "a Merkle tree
as described in Section 5.2.3" (or whichever number the description will
be in).

I can't find the format of RADI in the draft. It appears to be uint32.

It appears that there can be up to 32 members in the PATH array, but
this limit is not stated anywhere. With that many members, the PATH
array alone will be 2048 bytes in size. This could enable amplification
attacks and must be addressed. Furthermore, the path MTU on the public
Internet is normally 1500 bytes, which would require packet fragmentation.

Here's a tag tree with the tags' sizes in bytes:
[Header]  5*8 = 40 bytes
SREP      3*8 = 24 bytes
   * ROOT       64 bytes
   * MIDP        8 bytes
   * RADI        4 bytes
SIG             64 bytes
CERT      2*8 = 16 bytes
   * DELE 3*8 = 24 bytes
      - MINT     8 bytes
      - MAXT     8 bytes
      - PUBK    32 bytes
   * SIG        64 bytes
INDX             4 bytes
PATH          n*64 bytes

Except for the PATH tag, the sizes of the tags in a Roughtime reply are
fixed. Thus, with zero PATH members the minimum message size is 360
bytes. With PATH size (n) equal to 32, the maximum message size is 2408
bytes. The message size could be contained within 1024 bytes by limiting
n to 10. I haven't studied the Merkle tree structure in detail, so I
don't know if that's possible or what effects it would have.

Section 5.2.3 should be split into three sections: two describing the
INDX and PATH formats and one describing the Merkle tree data structure
and how the SREP ROOT is verified.

Section 5.3 is very clear and easy to understand.

I agree with Daniel Franke re Section 6.

Is the purpose of the JSON format mentioned in Section 7 to exchange
proofs of server cheating?

I don't understand the purpose of the grease described in Section 8.

The servers' public keys in Section 9 should all be in the same format
to simplify implementations.

The key for roughtime.int08h.com has been truncated. The correct key in
base64 format seems to be AW5uAoTSTDfG5NfY1bTh08GUnOqlRb+HVhbJ3ODJvsE=.

Nit: "hexidecimal" in Section 9 should be "hexadecimal".

Section 11 should include a request to IANA for a UDP port assignment.

Section 11 should include a request to IANA for a new registry for
Roughtime tag keys. Each assignment could include: the tag name (four
bytes), whether it is a parent or leaf tag, the data format/stride, and
a reference (i.e. RFC and section).

Roughtime is, like all other network time protocols, vulnerable to delay
and replay attacks by adversaries that control all or many of the
network paths to the client. This should be elaborated on in the
security considerations.

I haven't gone through the list of references in detail, but it seems to
me that some of them should be normative instead of informative.

Thank you for submitting this draft. I support its adoption by the
working group.

I hope any of this was helpful...

Kind regards,
Marcus Dansarie

On 2019-02-08 23:11, Aanchal Malhotra wrote:
> Hi All,
> 
> We have put together a draft for Roughtime. We encourage folks here to
> have a look at the draft and see if they think that there is a value in

---

From: Marcus Dansarie <[email-masked]>
Date: Sun, 10 Feb 2019 22:53:33 +0100

One more thing which I forgot:
The server implementations of Roughtime referenced in Section 9 prepend
'RoughTime v1 delegation signature--\x00' and 'RoughTime v1 response
signature\x00' to the delegation and response tags, respectively, before
signing them. This is currently not mentioned in the draft.

Kind regards,
Marcus Dansarie

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 11 Feb 2019 11:03:04 +0200

Hi Aanchal,

Thanks for putting this draft together.

A few clarification questions:
- What is the threat model? Please clarify in the draft what is the threat
that you are trying to address and is not addressed by the existing
protocols/solutions.
- Also please specify in the draft what you mean by 'malfeasance'. One
could speculate that this is identical to NTP's 'Falsetickers', and NTP's
clustering+combining algorithms (when used with authentication) address
Falsetickers.
- Please clarify in the draft what Roughtime achieves that NTP's
clustering+combining+authentication does not achieve.

And a minor comment: it would be helpful if the draft name would be
according to the IETF convention, something like
draft-aanchal-ntp-roughtime.

Cheers,
Tal.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 11 Feb 2019 11:05:17 +0100

>  https://tools.ietf.org/html/draft-roughtime-aanchal-00

Very intestersting. It's nice to have a specification of the protocol.

It's not very clear to me what can I do with the proof that a server
provided an incorrect time. Like with NTP, when that happens, it most
likely was a problem with the clock, e.g. migrated VM, bug in GPS
firmware, etc.

If this is useful, I think we should consider adopting the mechanism
as an NTP extension, so people could still have accurate
synchronization in the normal case when nobody is trying to spoof
time. Even if the crypto is expensive and the operations need to be
batched for multiple clients, I think with the interleaved mode it
would still be possible to get the accurate TX timestamp.

Maybe the Roughtime packet could simply be adopted as is as a single
NTP extension field and it could be used as an additional check of the
NTP timestamps?

Also, I'm wondering what would be the minimal change in NTS required
to construct the Roughtime proof.

-- 
Miroslav Lichvar

---

From: Thomas Peterson <[email-masked]>
Date: Mon, 11 Feb 2019 10:22:02 +0000

Responses inline.

Regards

> likely was a problem with the clock, e.g. migrated VM, bug in GPS
In the original Google specification[1], it suggests that clients can 
send information upstream (to where exactly is undefined) with the 
responses from servers providing incorrect time. As servers are 
identified by clients by several identifiers it would also obviously 
allow them to no longer be queried. For services like the NTP pool, this 
might be useful to act on servers reporting incorrect time and ensure 
existing or future clients do not use them.
> NTP extension field and it could be used as an additional check of the
I think that providing an NTP extension like this would be beneficial to 
existing deployments, but would like to see Roughtime adopted as its own 
standalone protocol. The undefined section I refer to above of what 
clients could do to propagate information about incorrect servers should 
also be addressed.
> to construct the Roughtime proof.
1: https://roughtime.googlesource.com/roughtime

---

From: Aanchal Malhotra <[email-masked]>
Date: Tue, 12 Feb 2019 16:48:50 -0800

Hi Daniel,

Thanks for the comment.

We agree to the general idea. However, I am not sure if I follow the
concrete idea. More specifically, I am not sure if I understand the intent
for separate message types for querying and communicating the historical
leap seconds & how does it create a malfeasance-evident mechanism for
distribution of leap second data. Can you please elaborate?

---

From: Marcus Dansarie <[email-masked]>
Date: Wed, 13 Feb 2019 21:29:48 +0100

As I mentioned during the virtual interim meeting, I have a few more
comments on the Roughtime draft:

First and most important: My general impression of the protocol is that
one of its greatest strengths is its simplicity. Any further development
must therefore be vary of scope creep. In particular, features that
require the server to keep per-client state or return tags tailored for
individual clients (except for INDX and PATH) should not be included.
The same goes for features that aren't directly related to the
protocol's goal of authenticated moderate accuracy (rough) time
synchronization.

In Section 5.2.1, the definition of what instance in time MIDP (+/-
RADI) is can be improved. Defining MIDP +/- RADI as the server's
estimate of the time interval in which the replies will actually leave
the network interface could improve the potential time accuracy. (See
also my next point.) Servers that don't want to or can't perform this
estimation can simply use the time of processing and set RADI
accordingly. (And the draft should probably mention that the error in
MIDP most likely won't follow a statistical distribution.)

Including an equivalent interval (say, RECV +/- RADR) in SREP for when
the replies included in the Merkle tree were received would, together
with the previous point, allow the clients to calculate the approximate
path delay. These tags could be optional for the server to include and
for clients to use.

Section 7 mentions a "64 bit blind". I think this was meant to say "64
byte blind".

The draft says nothing about how clients and servers should handle
unknown tags. My suggestion is that the default behavior should be to
ignore them.

The minimum requirement for leap second information provided by the
server should be an int32 containing the TAI-UTC offset at MIDP.
Requiring anything more would place requirements on regular maintenance
that can be hard to satisfy in all systems. Furthermore, a Roughtime
server with a GNSS receiver can operate completely standalone and still
be compliant.

Roughtime system related comments:

The draft mentions trust in servers. Technically, trust in the Roughtime
system is in the long-term public keys. All that can be proven by
chaining Roughtime requests is that a server using a delegate
certificate signed by a certain public key has misbehaved (or not).
Conversely, a distrusted server can restore trust simply by changing its
public key.

The ecosystem currently provides no means to revoke a compromised
delegate certificate. The simple solution to this is to recommend very
short-term delegate certificates, but this might cause implementation
issues on the server end. Some thought is probably needed here.

Someone (this is perhaps left to client implementers or auditors) will
have to decide how to measure trust in public keys. Possible metrics are:
- length of the time interval(s) that the key/server has provided good time;
- length or number of time intervals that the key/server has provided
bad time;
- number of time errors/incidents, and;
- the size of identified time errors.

As others have mentioned: How will clients find lists of (probably) good
time servers? This is really just another trust anchoring problem and
possibly an implementation issue. The users are placing a large amount
of trust in the implementer anyways. It is probably going to end up
being implementation dependent with a list of servers distributed with
the client and updated over HTTPS. An API specification for list
distribution would enable users to select their trusted source of
Roughtime server lists.

Clients that identify time inconsistencies or misbehaving time servers
must be able to report them somehow, i.e. there needs to be an API for
automatically notifying server list distributors, client implementers,
auditors, and server owners. (Well-behaved servers might turn themselves
off if presented evidence of malfunction signed by other time servers
trusted by them. This evidence will probably be sent out of band and not
via the Roughtime protocol.)

That's all for now...

Kind regards,
Marcus

---

From: Daniel Franke <[email-masked]>
Date: Wed, 13 Feb 2019 16:55:39 -0500

The idea of a separate query type for historical leap seconds is just
to conserve bandwidth. We don't want to be sending the whole table in
response to every time query.

Leap second queries would contain a nonce just like time queries, and
responses to leap second queries would be signed the same way response
to time queries are, making it easy to prove if a server was sending
bad leap second data and when it was doing it.

On Tue, Feb 12, 2019 at 7:49 PM Aanchal Malhotra <[email-masked]> wrote:
>
> Hi Daniel,
>
> Thanks for the comment.
>
> We agree to the general idea. However, I am not sure if I follow the concrete idea. More specifically, I am not sure if I understand the intent for separate message types for querying and communicating the historical leap seconds & how does it create a malfeasance-evident mechanism for distribution of leap second data. Can you please elaborate?
>

---

From: Tony Finch <[email-masked]>
Date: Thu, 14 Feb 2019 15:22:48 +0000

Daniel Franke <[email-masked]> wrote:

> to conserve bandwidth.

The leap second table can be very small:

6+6+12+12+12+12+12+12+12+18+12+12+24+30+24+12+18+12+12+18+18+18+84+36+42+36+18+35?

This format is interval in months, separated by leap signs (positive or
negative), starting from 1972.

[ I have a binary version which is (currently) 16 bytes. ]

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Channel Islands: Southeast 3 to 4, perhaps locally 5 at times, mainly
mid-channel. Smooth or slight, perhaps locally moderate mid-channel. Risk of
mist patches near french coasts early morning. Good, perhaps locally moderate
or poor near French coasts early morning.

---

From: Danny Mayer <[email-masked]>
Date: Thu, 14 Feb 2019 10:29:03 -0500

> The leap second table can be very small:

And for completeness how do you deal with negative leap-seconds, even
though that seems very unlikely?

Danny

---

From: Tony Finch <[email-masked]>
Date: Thu, 14 Feb 2019 15:48:30 +0000

> though that seems very unlikely?

Positive leaps are + negative are - and ? means unknown.

The binary version uses two bits with the same semantics as NTP leap
indicators.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Southeast 6 to gale 8. Moderate or rough. Fair. Good.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 14 Feb 2019 17:52:58 +0000

> The leap second table can be very small:
 
Use hex and save (ooh, neat coincidence) 12 bytes. "+12" -> "+C"