[Ntp] Google Roughtime Comments

[Ben Laurie <[e-mail]>]

At the meeting in London I said I'd send our comments on the Roughtime I-D.
Apologies for the delay, but here they are - the original authors are
copied in case of discussion.

By way of introduction, we represent several security focused teams in
google who are particularly interested in the Roughtime draft:
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-roughtime. Time is
important to security protocols in general, and Roughtime potentially
provides a system of accountability that would be very interesting for us.
In particular the properties of verifiability and diversification of trust
are key for our use cases.

We have a few bits of feedback on the current draft and are keen to
progress to the draft to RFC:

[Ceri] The introduction states that “the Roughtime protocol provides
cryptographic proof of malfeasance, enabling clients to detect and prove to
a third party a server's attempts to influence the time a client computes”
but the mechanism by which clients detect this malfeasance, chaining
Roughtime requests/responses, is not described in this paper. To prove the
thesis of the paper, a description of how clients accomplish chaining and
how they can detect malfeasance within the chain should be included since
those are essential parts of the protocol’s usage. Examples of what clients
do once they detect malfeasance would then fit well into the separate
Roughtime ecosystem paper.


[Hayden] Section 6.3 describes the use of a Merkle tree in the response.
Merkle trees are used to allow the server to batch requests while providing
an efficient format for clients that consume the request. This is not clear
from the description in 6.3 however, and I would propose adding in more
details from blogposts such as
https://int08h.com/post/to-catch-a-lying-timeserver and
https://blog.cloudflare.com/roughtime.


[Hayden] The I-D mandates the use of Ed25519 due to the signature size and
efficiency in computation of the signature. Roughtime server operators may
have other requirements on key usage however, and may prefer to use
different signature schemes. I would propose making the signature algorithm
configurable by the server. This will also be beneficial when considering
post-quantum, as we can simply update the list of recommended algorithms.


[Ben] Requiring the signing certificate to be sent in every packet means
that some algorithms will not be usable, since their certificates won’t
fit, and probably also means it won’t be possible to fit more than one
signature in the same packet (though I am not sure there’s a need for
this). It might be sensible to instead send a hash of the certificate and
have a separate way to request certificates which can then be cached.


[Ben] The language around versioning is confusing. The I-D says “The VER
tag MUST include at least one Roughtime version supported by the client.”
This obviously allows the client to send versions it does not support. Why
would a client ever want to do that? I feel like I’m missing something.
Also, “The client MUST ensure that the version numbers and tags included in
the request are not incompatible with each other or the packet contents.”
would seem to require authors of client code to do some deep thinking,
possibly incorrectly, to decide whether they will meet these criteria.
Given that there is currently only one version defined, perhaps language
around what can and can’t be done with versions should be a) more explicit
and b) in relation to particular versions - and hence not needed until
there actually is more than one version.


[Asra] Section 7 describes integrations into NTP and starts to mention
applications such as X.509 verification, for example, for short-lived
certificates. Like RFC 3161 support in X.509 verification (for proof of
signature creation time), it would be interesting to get alignment and/or
propose augmenting X.509 verification with Roughtime timestamps. Some
considerations would be length of responses and configuration of out of
band client trust for Roughtime server public keys, but the benefits would
extend for systems already using X.509 PKI.