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

From: Harlan Stenn <[email-masked]>
Date: Mon, 9 Sep 2019 21:43:14 -0700

I am opposed to the adoption of this draft at this time, even as an
Informational document.

I find the document as written omits too many details about assumptions
and conclusions to clearly, understandably, and reliably support its claims.

On 8/27/2019 10:32 PM, IETF Secretariat wrote:
> 
> The NTP WG has placed draft-roughtime-aanchal in state
> Call For Adoption By WG Issued (entered by Karen O'Donoghue)
> 
> The document was previously in state Candidate for WG Adoption
> 
> The document is available at
> https://datatracker.ietf.org/doc/draft-roughtime-aanchal/
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
> 

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Watson Ladd <[email-masked]>
Date: Mon, 9 Sep 2019 21:44:46 -0700

> and conclusions to clearly, understandably, and reliably support its claims.

I  would welcome specific suggestions for improvement or things you
find unclear.

---

From: Hal Murray <[email-masked]>
Date: Mon, 09 Sep 2019 23:33:55 -0700

[email-masked] 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.

---

From: [email-masked]
Date: Tue, 10 Sep 2019 12:52:42 +0200

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" <[email-masked]>
An:     "Watson Ladd" <[email-masked]>
Kopie:  "NTP WG" <[email-masked]>, "Harlan Stenn" <[email-masked]>
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" <[email-masked]>

> I  would welcome specific suggestions for improvement or things you find

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.)

---

From: Watson Ladd <[email-masked]>
Date: Tue, 10 Sep 2019 06:55:55 -0700

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

Because people cheat at Candy Crush Saga. To do this they change their
phone clocks and this is the leading cause of certificate validation
errors. With things like delegated credentials this becomes a bigger
problem.

> don't have a proof when it might be helpful.  (That assumes we are using

Some applications like PKI do not require extreme precision but do require
accuracy. We can of course not trust operators that return the wrong time.

---

From: Marcus Dansarie <[email-masked]>
Date: Tue, 10 Sep 2019 22:30:23 +0200

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.

Another important property of Roughtime servers is their ability to
function as general timestamping servers, which might be interesting for
some applications.

Kind regards,
Marcus Dansarie

On 2019-09-10 12:52, [email-masked] wrote:
> 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
> 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:
> 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
> 
> 
> 
> 
> Betreff:        Re: [Ntp] The NTP WG has placed draft-roughtime-aanchal
> in state "Call For Adoption By WG Issued"
> ------------------------------------------------------------------------
> 
> 
> 
>

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 11 Sep 2019 09:05:49 +0200

> 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.

-- 
Miroslav Lichvar

---

From: Marcus Dansarie <[email-masked]>
Date: Wed, 11 Sep 2019 13:06:41 +0200

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

---

From: Watson Ladd <[email-masked]>
Date: Wed, 11 Sep 2019 07:42:38 -0700

> implement than NTP, especially in some specific frameworks.

The signing negatively affects the possible timing accuracy, and you
need to track things differently on the server.

Based on discussions in Prague we're also adding TCP transport, which
doesn't work for NTP.

What are the benefits from adding it as an extension?

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 11 Sep 2019 17:01:15 +0200

On Wed, Sep 11, 2019 at 07:42:38AM -0700, Watson Ladd wrote:
> The signing negatively affects the possible timing accuracy

I think with the interleaved mode that wouldn't have to be the case,
but even if it was, why would it matter? It wouldn't be worse than
what is currently specified, right?

> and you

Meaning it would be more difficult to add the support to an NTP server
than implement it as a separate service?

> What are the benefits from adding it as an extension?

The "proof of malfeasance" could cover the timestamps that the client
is using to synchronize the clock. I'm not sure if there is any value
in that.

-- 
Miroslav Lichvar

---

From: Hal Murray <[email-masked]>
Date: Wed, 11 Sep 2019 19:47:47 -0700

[email-masked] said:
> 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. 

I think there are 3 ideas tangled up here.

1) A way for a server to sign that it has seen some bits.
2) A time stamp for that signing and some info about the server's clock.
3) A way to chain 3 signings to show that the middle time stamp is bogus.

I haven't yet seen an interesting use case for the 3rd part.

The first part may be appropriate for joint work another IETF group.

I'm very interested in a way to get the time.  NTS-KE uses traditional 
certificates and checking those needs a sane time.  Rough, even very rough 
would be great.

But I haven't seen that this draft solves the critical step.  How does the 
client get the server's public key?  The draft says:
            long-term public/private key pair  (page 4)
and
            We assume the long-term server public key is known to the
client through other means.  (page 10)

How much work has been done on those "other means"?

---

From: Marcus Dansarie <[email-masked]>
Date: Mon, 30 Sep 2019 20:23:18 +0200

> I haven't yet seen an interesting use case for the 3rd part.

Chaining multiple signings allows for creating proofs of bad behavior.
If a server owner purposely serves bad time to a small subset of users,
there is currently no way of proving that in existing time protocols.
(The server will appear sane to non-targeted users.) With Roughtime, the
target of such an attack can present proof that can be verified by anyone.

> The first part may be appropriate for joint work another IETF group.

Yes, a general timestamping protocol is probably of interest to others.

> How much work has been done on those "other means"?

My view on this is that it will have to be done in the same way as with
TLS root certificates: the operating system/client software will come
with a set of trusted public keys. The policy for inclusion is decided
by the software maintainers.

Kind regards,
Marcus