Subject: Re: [Ntp] Roughtime draft

From: [email-masked]
Date: Mon, 11 Feb 2019 10:23:11 +0100

Hi all,

I really like what the draft does, and I absolutely think there is merit 
in adopting it.

That said, I do have a few points that I would like to adress and discuss:

1) I kind of fall in line with Marcus' comment on Section 1: the 
unique-selling-point discussion seems slightly over the top.
It might be helpful to re-formulate to make clearer that Roughtime's 
novelty lies in the fact  that it explicitly makes an attempt at 
cryptgraphic ensurance of server accountability in the first place.

2) Also, I suggest to clarify what guarantees and assurances Roughtime 
intends to give, and more importantly: to whom.
After my first read-through, it seems to me that the enforcement policy is 
something like "if client X ever witnesses malfeasance by server Y, then X 
stops trusting Y" and that that is the full extent of it.
Did I miss instructions about how to actually submit cryptographic 
evidence of malfeasance, so it can be used to improve the health of the 
overall Roughtime environment (a proper, abuse-protected procedure for 
this seems non-trivial to me)?

2a) In case that I did not miss anything important and there simply is 
none:
The described functionality is nice, but I don't know that it delivers on 
the implicit promise that Roughtime would "ensure that the servers behave 
correctly".
This reverts back to 1): I support Marcus' point that any kind of 
cryptograhically secured NTP can supply similar functionality - arguably 
even better because it could detect more subtle versions of false time.
In order to make its novelty a practical benefit, Roughtime would have to 
include a procedure on how to use crypto evidence to improve its server 
environment.

2b) In case I did miss something, and Roughtime servers can actually be 
held accountable by the system (as opposed to by individual clients):
My first thought was that it would be possible to use Roughtime to "probe" 
known public trusted timeservers (that also use other protocols, such as 
NTP).
I was disappointed when I realized that this would not really be that 
helpful, since such probing would be 100% recognizable as such, and rogue 
servers are free to choose when to lie and when to simply revert to 
telling the truth...
I don't know if it makes any sense to go into this anywhere in the 
document, as it is a big strawman argument - but crypto-derived guarantees 
are notoriously hard to understand, and perhaps other people could be 
mislead as well if this is not discussed?

3) I completely agree with Daniel and the others that everyone would do 
well to use TAI over smeared time of any sort.
I just don't know if the issue is really open to debate anymore, as in: 
how wide-spread is use of Roughtime implementations at this point? 
Could a specification actually still influence a question like this?

None of this is meant to sound overly critical to the protocol or the 
document effort as such - I definitely see that Roughtime does provide 
novelty, even if I'm not convined that it is currently used optimally.
As stated, I think the draft should be adopted and discussed. 

Perhaps there is even a way to generically specify the procedure that 
Roughtime employs for its goal for use in other secured timesync 
procedures, such as NTS?
After all, the most important step seems to be to include data from 
previous responses in the nonces of future requests. (I don't think this 
is strictly prohibited in NTS right now?)

Thanks for all the work and best regards,
Kristof

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
> adopting/implementing it and would be interested to do so.
> 
>  https://tools.ietf.org/html/draft-roughtime-aanchal-00
> 
> Best,
> Aanchal.
> 
> 
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
> 

_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp