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

I concur with Hal's quick analysis and (broadly) with its implications.

While I'm not opposed to adoption of this draft, I don't currently see a 
particularly compelling reason to have it be an RFC either.
Specifically I don't (yet?) see how that meets any existing need or demand 
in NTP-related environments (which seems to me a good criterion for 
adoption in the NTP WG - but perhaps I'm off track there?).

To elaborate: Roughtime seems to offer a single feature over other secured 
timesync options, i.e. the ability to tell on a (certified and 
authenticated) server if it goes rogue and sends false time.
With that one feature in mind, I would really like for the draft to be 
clearer about use cases for Roughtime, specifically in relation to secured 
NTP (NTS, or even NTP-MD5) usage, which I kind of see as the default. In 
particular:
a) When does it make sense to use Roughtime instead of secured NTP?
b) When does it make sense to use Roughtime in addition to secured NTP? 
(Remember that a rogue server can tell the truth via Roughtime but 
falsehoods via NTP).
c) Do we want to somehow integrate Roughtime's features into NTP?-(I would 
find this interesting, but it does not seem to be the intent of the draft 
as written)

Best regards,
Kristof

Von:    "Hal Murray" <hmurray@megapathdsl.net>
An:     "Watson Ladd" <watsonbladd@gmail.com>
Kopie:  "NTP WG" <ntp@ietf.org>, "Harlan Stenn" <stenn@nwtime.org>
Datum:  10.09.2019 08:35
Betreff:        Re: [Ntp] The NTP WG has placed draft-roughtime-aanchal in 
state "Call For Adoption By WG Issued"
Gesendet von:   "ntp" <ntp-bounces@ietf.org>

watsonbladd@gmail.com said:
> I  would welcome specific suggestions for improvement or things you find
> unclear. 

I'm missing the big picture.  Why is this interesting?  Is this for some 
legal 
requirements?

Why invent a new packet format rather than use an extension on NTP 
packets?

Why is it interesting to have a convincing proof that server X returned 
the 
wrong time?  I see 3 cases:
  1) some new bug has been triggered, for example a GPS week number roll 
over. 
 (WNRO)
  2) the operator is sloppy or incompetent or ??? and has broken something
  3) the operator is a bad guy.

In case 1, the operator will fix the problem if we point it out.  A quick 
test 
is enough.  No proof needed.

In case 2, maybe they learn something, maybe they don't.  A proof won't 
help.

In case 3, the bad guy will give the truth to roughtime but lie on NTP. So 
we 
don't have a proof when it might be helpful.  (That assumes we are using 
NTP 
to get accurate time.)

-- 
These are my opinions.  I hate spam.

_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp