[Ntp] Roughtime update

[Marcus Dansarie <[e-mail]>]

All,

Here comes a quick summary of Roughtime developments during the 
Hackathon and NTP WG meeting at IETF 121 in Dublin.

# Hackathon results

We participated with Roughtime in the Hackathon this weekend. Overall, I 
think our participation was very successful, considering that we 
uncovered important issues with both the draft and several implementations.

Me and Sarah Grant worked on Plummet, an interoperability testing 
framework for Roughtime. Plummet creates a Docker container for each 
Roughtime implementation and uses the containers for testing each client 
against each server, logging outputs and packets. Results are available 
as individual log and pcap files as well as in condensed json and html 
formats. The result.html file produced by Plummet also contains a handy 
interoperability matrix and parsed Roughtime packets. Plummet can be 
found at https://github.com/ietf-wg-ntp/Roughtime-interop-code.

The following implementations are currently tested by Plummet:
* Cloudflare Roughtime (https://github.com/cloudflare/roughtime)
* Craggy (https://github.com/nahojkap/craggy)
* Node-Roughtime (https://github.com/bnoordhuis/node-roughtime)
* Pyroughtime (https://github.com/dansarie/pyroughtime)
* Roughtimed (https://github.com/dansarie/roughtimed)
* Roughenough (https://github.com/int08h/roughenough)
* Vroughtime (https://github.com/oreparaz/vroughtime)
Only Cloudflare Roughtime, Pyroughtime, Roughenough, and Roughtimed 
currently support draft-11. Pyroughtime and Roughtimed were updated to 
support draft-11 by me during the Hackathon. We also found bugs in other 
implementations which were reported to the respective authors.

After the bug fixes, the four draft-11 implementations appear to 
interoperate. There are however issues with some clients and the 
Roughenough server, which is not due to a problem with the wire 
protocol, but with how keys are defined. This is described below.

Additionally, Ruben Nijveld started work on a Roughtime server 
implementation in Rust.

# RFC 8032 and Roughtime keys

During testing with Plummet, there was problems getting interoperability 
between the Roughenough server and the Cloudflare and Pyroughtime 
clients. The reason for this was identified as being due to Roughenough 
treating key seeds/private keys different than other implementations. 
RFC 8032 specifies EdDSA and specifies how private keys should be 
generated from a random seed. In particular, certain bits of the private 
key have to be cleared and one has to be set in order to prevent 
small-subgroup attacks and timing side-channel leaks. Depending on which 
Ed25519 libraries the different implementations use and how those 
libraries are called, this requirement may not be met or treated in the 
same way by all implementations. I will do some investigation and report 
when I know more.

In any case, the draft needs to be updated with language that requires 
private keys to be generated in accordance with RFC 8032. The draft 
should also clearly specify how the expressions "public key" and 
"private key" in the draft relate to the definitions in RFC 8032.

# Version downgrade attacks

During discussions at the Hackathon between myself, David, and Ruben, we 
realized that man-in-the middle attacks are possible on the versions 
sent in the VER tag by both servers and clients. The suggested fix to 
this is to include a hash of the entire request packet in the Merkle 
tree, instead a hash of just the NONC value. This will make possible for 
the client to detect changes to any and all bits of the request. 
Additionally, the VER tag in the server's response should be moved into 
the SREP tag. (We should also add a recommendation in the security 
considerations that any new or implementation-specific tags SHOULD be 
added to SREP, so that tampering can be detected.) A new tag, containing 
a list of the server's supported versions should also be added to the 
SREP tag.

# Lack of client checks

During the Hackathon, we noticed that many clients do not do proper 
checking of received responses. This highlights the need for greasing by 
servers.

# Possible regression between draft-07 and draft-08

In draft-07, the context string "RoughTime v1 delegation signature--" 
was changed to "RoughTime v1 delegation signature", for consistency with 
the other context string used in Roughtime. However, this was reverted 
in draft-08. I do not recall if this was deliberate or if it appeared 
accidentally when other changes were reverted. Does anyone else 
remember? For consistency, I think we should remove the dashes again, at 
the same time as we make other breaking changes.

# Max Merkle tree height

Ruben pointed out that the maximum Merkle tree height is not explicitly 
specified in the document. It is implicitly specified, since response 
messages are limited in length. To help implementation developers, 
perhaps we should specify the maximum height explicitly?

# Multiple version numbers allowed in requests

Ruben also pointed out that the multiple version numbers in requests are 
tricky to implement. On the other hand, there are currently client 
implementations that make use of this feature for interoperability 
between different draft versions and it seems to be working well. Are 
there any opinions or experiences on this?

# Editorial issues

Dieter and I discussed a number of editorial issues with the draft 
during the Hackathon. In particular, Dieter pointed out that the 
language about what Roughtime guarantees is unclear and has changed 
between draft versions.

# The way forward

I was hoping to release a new version of the draft this weekend, without 
any breaking changes to the on-wire protocol. However, since we are 
going to need to make changes, at least when it comes to VER tag 
handling, I decided to wait with publishing a new version until those 
fixes have been included. Hopefully, implementations can be quickly 
updated to support that draft and interoperate, which would enable us to 
move towards WG last call.

The full list of current issues with the draft is available on Github: 
https://github.com/ietf-wg-ntp/draft-roughtime/issues.

Any input or suggestions on the above - or anything else 
Roughtime-related - is greatly appreciated.

Kind regards,
Marcus