Re: [Ntp] ntpv5 requirements

> Von: "Dieter Sibold" <dsibold.ietf@gmail.com>
> Betreff: Re: [Ntp] ntpv5 requirements
> 
> RFC 4082 describes TESLA in the context of multicast/broadcast only.
> Hence, I?m not sure that the security guarantees of the TESLA 
> approach are valid for the client-server mode. Before thinking about
> some TESLA like approach only for the sake of performance we would 
> need to clarify this question. Preferentially, this should be done 
> by a security analyst.

I think we know enough about TESLA to answer this.
- Yes, it is explicitly meant and designed for broadcast purposes, using 
it for client-server is not even close to its intended use-case
- It requires/assumes rough synchronicity in the first place; and if we 
allow unsecured synchronisation during initialisation, we kind of defeat 
ourselves
- Related: It has a documented weakness when used for securing time 
transfer messages (i.e., delay attacks affect it *much* worse than they 
affect other security schemes, because they can affect that assumed rough 
synchronicity) 
- It won't allow instant authentication, you have to wait out the key 
disclosure time; you can either wait longer before processing your time 
transfer message, or keep those times short and compound your security 
problem with the required synchronicity
- It also (someone already noted this) requires initial setup exchanges 
with expensive crypto; and of course less-expensive symmetric crypto for 
time transfer messages... so what performance would we even be saving?

I feel like we went to buy something to help us drive nails into a wall, 
don't like the hammer that's on sale, and are now wondering aloud about 
buying that two-man crosscut saw.

> PTB enhanced all its public facing NTP servers with NTS. We observe 
> that NTS traffic is increasing but slowly. In case of PTB the amount
> is smaller than 1% of the total traffic. Hence it should be safe for
> the NIST to enable NTS also. Beside, if the amount of traffic is 
> going to be a problem the NTP and NTS service can also be provided 
> by FPGA; see for example Netnod?s NTS service.

I agree completely. 
Between the option for separate NTS key servers and the FPGA 
implementation, scaling should not actually be a problem.
It is just additional hardware, not something really prohibitive like a 
giant list of keys that needs to be managed manually; I'm just guessing 
around here, but maybe Judah was still thinking of that (from 
symmetric-key NTP security days) for some reason?

> Dieter
> 
> > Am 15.02.2023 um 04:10 schrieb Harlan Stenn <stenn@nwtime.org>:
> > 
> > I don't see that you are disagreeing with me regarding the 
> "priority" of performance.
> > 
> > And blindly following "amplification goal-stated as zero" has some
> pretty onerous consequences.
> > 
> > H
> > 
> > On 2/14/2023 4:28 AM, kristof.teichel@ptb.de wrote:
> >> The reason that scalability and performance have traditionally 
> been listed last in NTS documents is less that they are in any way 
> secondary -- and more that they follow a pattern of "...and it needs
> to do all of the above in such a way that it retains scalability and
> performance as far as possible".
> >> (And perhaps a bit of them being quantitative goals rather than 
> absolute/qualitative; performance is gonna get worse with crypto 
> rather than without, the goal is to keep it reasonable/best possible
> -- whereas e.g. amplification can be cleanly goal-stated as zero.)
> >> 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
> >> E-Mail: kristof.teichel@ptb.de
> >> __________________________________________
> >> Von: "Harlan Stenn" <stenn@nwtime.org>
> >> An: ntp@ietf.org
> >> Datum: 13.02.2023 23:29
> >> Betreff: Re: [Ntp] ntpv5 requirements
> >> Gesendet von: "ntp" <ntp-bounces@ietf.org>
> >> 
------------------------------------------------------------------------
> >> On 2/13/2023 8:06 AM, Miroslav Lichvar wrote:
> >>> On Thu, Feb 09, 2023 at 05:18:20PM +0000, Doug Arnold wrote:
> >>>> For example: Judah Levine at NIST recently told me that he 
> cannot  implement NTS with his current server resources and the number 
of
> >> clients NIST supports.  However, when I told him about TESLA he 
> thought a scheme based on that would be doable, as long as the keys 
> didn?t have to change too often.
> >>> That is interesting as NTS was specifically designed to scale well 
to
> >>> very large numbers of clients.
> >> I don't recall performance in NTS as being a primary goal of the 
design.
> >> Sure, it was listed as *a* goal, but the primary goals were around
> >> "security".
> >>> Is their concern about decryption
> >>> and encryption of NTS-protected NTP packets, or rather TLS in 
NTS-KE?
> >> >
> >>> In 2016 they reported they had about 200k requests per second across
> >>> all their servers [1]. Even if it was 100x more today and all 
clients
> >>> were using NTS, that could still be handled by a dozen of servers 
with
> >>> multi-core CPUs and AES acceleration. In my tests I get about 200k/s
> >>> per core.
> >> From what I've heard, NTS key operations take 5-10x the amount of
> >> compute power beyond what NTP needs.
> >>> NTS-KE traffic is more difficult to predict as it depends on the
> >>> client implementations. I would be curious to see what NTS-NTP to
> >>> NTS-KE request ratio do the well-known NTS providers like Cloudflare
> >>> and Netnod have.
> >>> [1] https://nvlpubs.nist.gov/nistpubs/jres/121/jres.121.003.pdf
> >> <https://nvlpubs.nist.gov/nistpubs/jres/121/jres.121.003.pdf>
> >> --
> >> Harlan Stenn <stenn@nwtime.org>
> >> http://networktimefoundation.org <http://networktimefoundation.org/
> >- be a member!
> >> _______________________________________________
> >> ntp mailing list
> >> ntp@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ntp <https://www.ietf.org/
> mailman/listinfo/ntp>
> > 
> > --
> > Harlan Stenn <stenn@nwtime.org>
> > http://networktimefoundation.org - be a member!
> > 
> > _______________________________________________
> > ntp mailing list
> > ntp@ietf.org
> > https://www.ietf.org/mailman/listinfo/ntp
> 
> [Anhang "signature.asc" gelöscht von Kristof Teichel/PTB] 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp