Re: [Ntp] Antwort: Why Roughtime?

[Ben Laurie <[e-mail]>]

On Mon, 18 Dec 2023 at 15:20, <martin.langer=[e-mail]> wrote:

> Hello all,
>
> But if I configure an NTS server in my client and the keys and
> certificates are valid,
> then I would expect the server not to intentionally send me false time
> information.


Why?

 ...and if I have multiple NTS-secured time servers, then the client can
> also protect
> itself against Byzantine errors.


>
> I'm still not really convinced by the server malfeasance mechanism. Is
> this really
> necessary for a "rough" time? What are the advantages over handling
> Byzantine
> errors or using something like NTP pools?


Evidence - badly behaved servers, whether deliberately so or not, can have
their behaviour revealed and get removed from pools.

In my humble opinion, Roughtime offers an advantage if I have weak hardware
> that doesn't or can't do TLS, so you just digitally sign the time
> information directly.
>
> I'd be happier if it didn't give the impression (as it does in some blogs
> and papers)
> that Roughtime solves the chicken-and-egg problem.


Verifiable transparency (and that is definitely the way I prefer to think
about roughtime) has been shown to be useful as a security mechanism. Since
time is absolutely key to many security protocols, we need high assurance
that time is correct. NTS provides no *verifiable* assurance at all,
roughtime does.


> I also want Roughtime to be
> minimalistic. ...why not just sign a Unix timestamp in seconds or max.
> milliseconds
> with EC or ED25519 and send it from the server to the client?  ...or NTPv4
> with an
> extension field containing a digital signature.  ...something like that as
> a suggestion.
>
> but I may be seeing several things wrong. ...I'm always happy to be proven
> wrong.
>
> kind regards,
> Martin
>
> __________________________________________
>
> Dr.-Ing. Martin Langer
> Physikalisch-Technische Bundesanstalt (PTB)
> Working Group 4.42 "Dissemination of Time"
> Bundesallee 100,
> 38116 Braunschweig (Germany)
> Tel.: [phone] <+49%20531%205924470>
> E-Mail: [e-mail]
> __________________________________________
>
>
>
> Von:        "Ben Laurie" <benl=[e-mail]>
> An:        kristof.teichel=[e-mail]
> Kopie:        "Hal Murray" <[e-mail]>, [e-mail]
> Datum:        18.12.2023 15:11
> Betreff:        Re: [Ntp] Antwort: Why Roughtime?
> Gesendet von:        "ntp" <[e-mail]>
> ------------------------------
>
>
>
>
>
> On Mon, 18 Dec 2023 at 08:09, <kristof.teichel=*[e-mail]*
> <[e-mail]>> wrote:
> Hey Hal, all,
>
> I whole-heartedly agree with Hal's points.
> In June, Martin and I sent a lengthy mail containing feedback on the
> Roughtime draft.
> Perhaps there was too much in there for these points (malfeasance
> reporting is unclear what it would actually do; no malfeasance report
> doesn't mean good intentions; any security protocol could just ditch key
> lifetimes and go back to pre-shared keys [and thereby eliminate TLS] with
> little extra work, NTS too) to really come through succinctly, but all of
> them have been concerns of ours as well.
>
> Further, I still think it is a bad idea to say 'We solve the
> chicken-and-egg problem of bootstrapping' with what seems like a mere
> reduction of a security feature (key lifetimes). It feels more like
> navigating around one of the operational ways in which the problem
> manifests rather than solving it (which makes sense, since the problem is
> probably fundamentally unsolvable). And to be clear: I'm not saying at all
> that it's bad to use long-term keys - I am just saying it's dangerous to
> imply that this is the bootstrapping solution the world has been waiting for
>
> I think you've both missed an important point: if an NTS server gives me
> incorrect time and I point that out, there's no way for you to know, in
> general, whether my claim is true or not. With roughtime, I can present
> evidence.
>
> Besten Gruß / Kind regards,
> Kristof Teichel
>
> __________________________________________
>
> Dr.-Ing. Kurt Kristof Teichel
> Physikalisch-Technische Bundesanstalt (PTB)
> Arbeitsgruppe 4.42 "Zeitübertragung"
> Bundesallee 100
> 38116 Braunschweig (Germany)
> Tel.: *[phone]* <+49%20531%205924471>
> E-Mail: *[e-mail]* <[e-mail]>
> __________________________________________
>
>
> -----"ntp" <*[e-mail]* <[e-mail]>> schrieb: -----
> An: *[e-mail]* <[e-mail]>
> Von: "Hal Murray" <*[e-mail]* <[e-mail]>>
> Gesendet von: "ntp" <*[e-mail]* <[e-mail]>>
> Datum: 17.12.2023 05:35
> Kopie: "Hal Murray" <*[e-mail]* <[e-mail]>>
> Betreff: [Ntp] Why Roughtime?
>
> I think Roughtime has 2 goals:
>
> The first is:
>   Furthermore clients may lack even a basic idea of the time, creating
>   bootstrapping problems. Roughtime uses a list of keys and servers
>   to resolve this issue.
>
> The second is:
>   Roughtime is a protocol for rough time synchronization that
>   enables clients to provide cryptographic proof of server malfeasance.
>
> Why do we need a separate protocol and separate servers?
>
> For the bootstraping problem, the important idea is key lifetime.  NTS
> uses traditional web certificates and their root certificate bundle.  The
> root certificate bundle is distributed and maintained by OSes/distros so
> NTS doesn't have to operate a separate key distribution mechanism.  That
> path has a limited key lifetime policy.  If it isn't long enough, we will
> have to use self signed certificates and invent a new key distribution
> mechanism.  Roughtime has the same problem so whatever they are planning to
> use for key distribution can be used by NTS to distribute their self-signed
> root certificates.
>
> Note that "lifetime" is a potentially ambiguous term.  Suppose you get a
> certificate with a 2 year lifetime.  That clock starts ticking when you
> purchase the certificate.  After a year, the useful lifetime is the time
> remaining, only 1 year.  The clock keeps ticking while the box and firmware
> are sitting on a retail shelf or the spares shelf.
>
> We should issue a new key every year or so even if their lifetime is 10s
> of years.  There is no significant cost to a server to support 100s of
> keys.  The newer ones will have a longer useful life -- last year's key
> will expire a year before this year's key.
>
> What is Roughtime's target market?  What sort of key lifetime does that
> need?
> How about traffic volume?
>
>
> On to server malfeasance.
>
> I'm curious about the proof part.  Is Roughtime planning to take server
> operators to court?
> Where else would you need a strong proof as compared to "Hey, your server
> is broken!"?
>
> The NTP pool has a monitoring system that drops a server when it doesn't
> respond or returns time that is too far off.  It sends email to the
> operator.
>
> NTS already signs NTP packets and that includes a nonce field.  The catch
> is that the key used for signing each packet is a client-server working key
> rather than a private key of a public/private pair.  We can fix that by
> adding a slot to NTS-KE which is the KE server signing the working key with
> it's private key.  (If the working key is exposed in a malfeasance report,
> the client needs to run NTS-KE again to get a new one.)
>
> Wikipedia says;
>   Malfeasance is the willful and intentional action that injures a party.
>
> The proof scheme described by Roughtime doesn't prove the "willful and
> intentional" part.  Servers screwup because of bugs in software, firmware,
> or hardware as well as network troubles and bad luck and inadequate
> operational procedures.
>
> There is another aspect to consider.  The lack of malfeasance reports
> doesn't prove correct operations.  If a bad guy takes over a server, he can
> respond correctly except to the system he is attacking.  You can't depend
> on monitoring by other sites.
>
>
> In recent mail, Chris mentioned "consensus".  NTP already does that.  Does
> Roughtime have better heuristics for consensus than NTP is using?
>
>
> Have I missed something that Roughtime does and NTP can't do with a simple
> extension?
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> _______________________________________________
> ntp mailing list
> *[e-mail]* <[e-mail]>
> *https://www.ietf.org/mailman/listinfo/ntp*
> <https://www.ietf.org/mailman/listinfo/ntp>
> _______________________________________________
> ntp mailing list
> *[e-mail]* <[e-mail]>
> *https://www.ietf.org/mailman/listinfo/ntp*
> <https://www.ietf.org/mailman/listinfo/ntp>
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp
>
>
>