Re: [Ntp] The NTP WG has placed draft-roughtime-aanchal in state "Call For Adoption By WG Issued"

[Marcus Dansarie <[e-mail]>]

Yes, it's becoming apparent that the draft needs to include the
motivations for the Roughtime protocol. The impression I've got about
Roughtime so far, and the reason for why I'm a proponent of it, is that
it is small, simple, and easy to implement. I view it mainly as a way
for end user applications (browsers etc.) and embedded devices of all
sorts to get a "good enough" time for bootstrapping, verifying
certificates and similar.

The ability to provide proof of malfeasance is good in situations where
the security of a system is dependent on time being accurate. Hopefully,
it will also deter any nefarious actions against users from Roughtime
server operators. For example: Someone with bad intent could set up a
pool of time servers that provides a high-quality service to almost all
users and thereby gain the trust of the community. That operator could
then misuse that trust to serve bad time to a small subset of targets
within the large user base. In this case, the target of the attack can
provide proof of this and refute the "works for me" argument from the
non-targeted users.

Kind regards,
Marcus Dansarie


On 2019-09-11 09:05, Miroslav Lichvar wrote:
> On Tue, Sep 10, 2019 at 10:30:23PM +0200, Marcus Dansarie wrote:
>> As someone (Daniel or Watson?) said in today's interim meeting: the
>> purpose of Roughtime is generally not to set the system's clock, but for
>> other purposes such as certificate verification.
> 
> It would be good to explain that in the draft. But I'm not sure how
> exactly that makes it different from NTP. An NTP client doesn't have
> to synchronize the system clock and it doesn't need any special
> privileges. There are of applications that don't trust the system
> clock and use NTP to verify the current time, even though it might
> seem like a terrible idea.
> 
> If I understand it correctly, Roughtime could be specified as an NTP
> extension field, possibly as an extension to NTS. So, I think the
> document should explain why a new protocol using a different transport
> was needed. I guess one reason could be that Roughtime is easier to
> implement than NTP, especially in some specific frameworks.
>