Re: [Ntp] Antwort: Why Roughtime?

On Mon, 18 Dec 2023 at 08:09, <kristof.teichel=40ptb.de@dmarc.ietf.org>
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.: +49 531 592-4471 <+49%20531%205924471>
> E-Mail: kristof.teichel@ptb.de
> __________________________________________
>
>
> -----"ntp" <ntp-bounces@ietf.org> schrieb: -----
> An: ntp@ietf.org
> Von: "Hal Murray" <halmurray@sonic.net>
> Gesendet von: "ntp" <ntp-bounces@ietf.org>
> Datum: 17.12.2023 05:35
> Kopie: "Hal Murray" <halmurray@sonic.net>
> 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
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>