Re: [Ntp] NTPv5 draft

[Magnus Danielson <[e-mail]>]

Marcus,

On 2020-12-08 15:50, Marcus Dansarie wrote:
> On 2020-12-07 17:38, Salz, Rich wrote:
>> My view is that it is no longer acceptable to design a protocol for
> deployment on the open Internet that has no authentication or message
> integrity and that people who disagree are out of consensus.
>
> On 2020-12-07 23:25, Philip Prindeville wrote:
>> I think that “private networks” and the notion of “the Intranet as
> implicitly secure” and the term “inside the perimeter” will fall by the
> wayside before 2030.
>
>> Those that don’t think they need security inside their perimeter are
> simply those that haven’t had an insider attack, or someone bring in a
> contaminated laptop onto the campus network, etc… or haven’t yet
> realized that they have.
>
> On 2020-12-08 15:20, Salz, Rich wrote:
>> I'll claim that I already have, but to restate and scale it down a
> bit: all messages sent by a server must include authentication and
> tamper-proof. I do not believe anything less is acceptable these days.
>
> Add me to the list of proponents of mandatory security in NTPv5.
> Protocols being designed today MUST enforce security. The problem we
> have to address is how to achieve this in a way that aligns with users'
> needs. Someone setting up an appliance for personal use, on an intranet,
> or airgapped network might not be interested in keeping certificates
> updated, distributing keys or stuffing them in DNS, and such. Trust on
> first use may be an acceptable scheme in those cases.

Agree fully. You bring up a point which I think not all is appreciating.
While we may develop protocols for the Internet, does not mean that they
actually have access to the network, or that such access is open in any
normal sense. For such air-gaped networks update cycles can also be long
enough that for instance leap-second file cannot be sent along each
upgrade to ensure correct leap-second list that way.

So, this just comes to illustrate that the user of the technology may be
facing very different requirements. However, we see that most users
experience such threats over their network, public internet or not, that
security mechanisms needs to be assumed mandatory for most. So, rather
view it as an added feature, flip the view around and look at the normal
case being that with security enabled, and then for those odd cases for
which it is neither needed or practical, consider the non-secured case a
special case.

Also, we should consider that the security mechanisms as well as their
artefacts such as certificates, is in constant albeit slow change. We
should therefore always view this as a constant migration. This is
important both as we design protocols and deploy them, but also as we
put requirements on systems and they are procured and put in operation
and then maintained, the migration may be very controlled, but also ongoing.

Cheers,
Magnus