Subject: Re: [Ntp] NTPv5 draft

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 1 Dec 2020 09:12:03 +0100

On Mon, Nov 30, 2020 at 08:12:06PM +0100, Dieter Sibold wrote:
> 1. Security
> 
> The protocol as proposed is missing a security approach. There are no
> mechanisms described to provide authentication, integrity protection and
> maybe encryption.

The draft describes a MAC extension field, using the AES-CMAC
(RFC8573). It also allows all NTPv4 extension field to be used in
NTPv5, making it compatible with the NTS specification.

> I very much agree with Jame’s proposed draft that a new
> version of NTP must provide these mechanisms by default.  Sure, you can add
> NTS to protect the NTPv5 packets. But in this case protection is always an
> optional add-on whereas it needs to be an inherent part of the basic
> protocol. To achieve this the NTS approach certainly can be transferred to
> the basic v5 protocol and packet format.

You mean to require all NTP packets to be authenticated? I don't like
that idea. The improvements in NTPv5 are orthogonal to authentication.
NTPv5 is not supposed to be more secure. An NTP client that doesn't
want to implement the complexity of NTS shouldn't be restricted to
NTPv4.

> 2. Interleave and 2-Step
> 
> I agree with Doug to decide with approach to provide with NTPv5. Providing
> both 2-Step and Interleave may increase complexity unnecessarily.
> Personally, I find that the 2-step approach with the follow-up message is
> more concise. And since the first message only need to be very small (it
> just needs to contain the information to ensure correlation with the follow
> up) the waste of network bandwidth is very small.

If we must to support only one of them, I think it should be the
interleaved mode.

- It fits better software server implementations, which is what the
  vast majority of NTP servers seems to be.
- It is simpler to implement on clients. It doesn't require timeouts
  for follow-up messages and handling of reordered packets.
- It is inherently resilient to amplification. No risk of an
  implementation having a bug in its cookie generation, or leaking
  key, which would allow attacks.

> 3. Traceability
> 
> It would make sense that the v5-packets optionally provide information about
> the uncertainty of the timestamps taken. These formally for establishing
> traceability.

Isn't that the NTP root delay and dispersion? Together they provide an
estimate of the maximum error in the receive and transmit timestamp.

> Additionally, in order to maintain traceability during the
> time period in which leap smearing is applied the client needs to obtain the
> necessary information to calculate the offset between UTC and smeared time.
> This also is mandatory to maintain traceability.

The smearing offset is provided in the Timescale Offset field.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 1 Dec 2020 09:20:03 +0100

On Mon, Nov 30, 2020 at 02:32:35PM -0600, Steven Sommars wrote:
> Agree, these fields could use better descriptions or (better) replacement.
> 
> One manufacturer (LeoNTP) lowers precision to indicate reduced accuracy and
> claims to obey the NTP specification.

I think that's just a workaround for limited resolution of the root
dispersion field. That's no longer a problem with the NTPv5 draft,
where the field has a resolution of 3.7 nanoseconds.

> Should a stratum 1 NTP server report root distance=0  ?   National labs
> differ.

If we ignore rounding, then no, there is no single clock that can
claim to be perfectly accurate to UTC. I think the only case where it
makes sense to report a dispersion and delay of exact zero is a clock
in the local/orphan mode, which is the "true" time for an isolated
network.

> Using NTP short format the smallest non-zero root dispersion is 15
> microseconds.  One can argue for finer granularity

The draft does that.

-- 
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 01 Dec 2020 09:30:35 +0100

>>> Steven Sommars <[email-masked]> schrieb am 30.11.2020 um 21:32 in
Nachricht
> claims to obey the NTP specification.

Actually if you consider precision to be a "runtime value" (as opposed to a "design value") it's obvious that it is actually variable. However the  overhead to update the value was considered too heavy in NTP design, I guess.

> Should a stratum 1 NTP server report root distance=0  ?   National labs

Would that mean that delay and dispersion are constant?

> microseconds.  One can argue for finer granularity

Not just there: stability (clk_wander) could also need more digits. clk_jitter is another candidate (it looks like a constant here for GPS). Maybe more. Some are heritage of microsecond resolution of NTPv3.

Regards,
Ulrich

> 
> Steve Sommars
> 
> 
> 
> 
> 
> On Mon, Nov 30, 2020 at 2:03 PM Kurt Roeckx <[email-masked]> wrote:
> 
>> The NTPv4 packet contains 3 fields that's related to the
>> uncertainty: precision, root delay, root dispersion. I'm not sure if
>> anybody is using the precision for anything, but it also has an
>> effect on the uncertainty.
>>
>> I'm wondering if the combination of those 3 fields is useful, and
>> if we need other fields to replace them. We at least need some
>> specification on how to calculate the values. Is the root distance
>> a mean, filtered or last value? Does the dispersion field have a 95%
>> (k=2) confidence interval?
>>
>> I think the document, at least the version in git, has an
>> extension for that.
>>
>>
>> Kurt
>>
>> _______________________________________________
>> ntp mailing list
>> [email-masked] 
>> https://www.ietf.org/mailman/listinfo/ntp 
>>

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 1 Dec 2020 09:44:48 +0100

> Actually if you consider precision to be a "runtime value" (as opposed to a "design value") it's obvious that it is actually variable. However the  overhead to update the value was considered too h…

I think it depends on the clock. Normally, the precision of the clock
should be constant. If it's a CPU with variable frequency, for
timekeeping performance it is better to set the frequency to a
constant value.

> Not just there: stability (clk_wander) could also need more digits. clk_jitter is another candidate (it looks like a constant here for GPS). Maybe more. Some are heritage of microsecond resolution…

Those values are provided only in the monitoring protocol.

-- 
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 01 Dec 2020 09:48:11 +0100

>>> Doug Arnold <[email-masked]> schrieb am 30.11.2020 um 23:12
in
Nachricht <[email-masked]>:
> RE security: 
> I think that there is a possibility of a non safety-critical closed network

> application of ntp that does not need security.  Especially if the client
has 
> a limited processor implementation.  I don't know, a golf course watering 
> system or something.

I think an interesting point is this: Do people think they don't need
security, because

1) it costs extra CPU cycles
2) it's difficult to set up and maintain
3) it brings no benefit

As Doug pointed out there are use cases for 3), but when 1) and 2) become
practically meaningless, many people won't care about 3), I guess.

> 
> Mandatory or not, I think that security should be added to the protocol as 
> an extension field, and described in another document.  Security mechanisms

> change frequently.  I think that there is a good chance that we, or someone,

> will define a successor to NTS within 10 years.  But the over the wire ntp 
> specification might last longer.  One of the virtues of Miroslav's proposal

> is that the minimum ptp message and protocol are simple and everything else

> is an extension. 

Yes, cryptography must be flexible.  Maybe just to meet legal restrictions for
some countries.

Regards,
Ulrich

> 
> Doug
> 
> On 11/30/20, 2:12 PM, "ntp on behalf of Dieter Sibold"
<[email-masked] 
> on behalf of [email-masked]> wrote:
> 
>     Hi Miroslav
> 
>     Many thanks for your NTPv5 proposal.
> 
>     With my working group chair’s hat off!
> 
>     I have following comments:
> 
> 
>     1. Security
> 

> 
>     maybe encryption. I very much agree with Jame’s proposed draft that a 
>     new version of NTP must provide these mechanisms by default.  Sure, you

>     can add NTS to protect the NTPv5 packets. But in this case protection is

> 
>     always an optional add-on whereas it needs to be an inherent part of the

> 
>     basic protocol. To achieve this the NTS approach certainly can be 
>     transferred to the basic v5 protocol and packet format.
> 
> 
> 
> 
>     2. Interleave and 2-Step
> 
>     I agree with Doug to decide with approach to provide with NTPv5. 
>     Providing both 2-Step and Interleave may increase complexity 
>     unnecessarily. Personally, I find that the 2-step approach with the 
>     follow-up message is more concise. And since the first message only need

> 
>     to be very small (it just needs to contain the information to ensure 
>     correlation with the follow up) the waste of network bandwidth is very 
>     small.
> 
> 
> 
>     3. Traceability
> 
>     It would make sense that the v5-packets optionally provide information 
>     about the uncertainty of the timestamps taken. These formally for 
>     establishing traceability. Additionally, in order to maintain 
>     traceability during the time period in which leap smearing is applied 
>     the client needs to obtain the necessary information to calculate the 
>     offset between UTC and smeared time. This also is mandatory to maintain

>     traceability.
> 
> 
>     Dieter
> 
> 
> 
> 
> 
> 
> 
> 
> 
>     On 11 Nov 2020, at 17:19, Miroslav Lichvar wrote:
> 
>     > As promised on the previous meetings, I wrote an NTPv5 draft. It's
>     > based on the proposal I sent to this list few months ago, with few
>     > improvements like timestamp fields seperated from cookies, etc. It
>     > still needs a lot of work to be able to stand on its own, but I think
>     > it should be good enough for people here to understand how it is
>     > intended to work.
>     >
>     > It's too late to submit it for the upcoming meeting. Here is a link
to
>     > a txt version if anyone would like to read it and discuss it here:
>     >
>     > https://gist.github.com/mlichvar/2bee94a706d60da9ca88d712afef083e 
>     >
>     > -- 
>     > Miroslav Lichvar
>     >

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 1 Dec 2020 09:50:51 +0100

> want to implement the complexity of NTS shouldn't be restricted to

As far as I know, it's currently still not possible to use NTS
with the pool, so we can't always use the authentication.

If devices like switches can be involved in the protocol too, do
we also want their data to be authenticated?

Kurt

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 01 Dec 2020 09:52:34 +0100

>>> "Salz, Rich" <rsalz=[email-masked]> schrieb am 01.12.2020 um
00:44
in Nachricht <[email-masked]>:
>>     I think that there is a possibility of a non safety‑critical closed 
> network application of ntp that does not need security.
> 
> I am strongly opposed to this for three and a half reasons:
> 1. The use‑case is not known, so we should assume that NTPv4 is good
enough.
> 1.5 If this is not the case, those who need this need to make the argument 
> to this WG.
> 2. Security should no longer be optional for IETF protocols.
> 3. "Closed network" is increasingly unlikely; we're seeing more things "in 
> the cloud" for example.

"more" isn't all: I know some "devices" that actually consist of several
computers in one cabinet taling to each other via a network you cannot see or
reach from the outside. That could be a candidate where no extra security is
needed. Also see my earlier message on the subject.

Regards,
Ulrich

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 01 Dec 2020 09:54:38 +0100

>>> Philip Prindeville <[email-masked]> schrieb am 01.12.2020 um
01:13 in Nachricht
<[email-masked]>:
> Disagree.
> 
> Too many vulnerability exploits have their genesis in things being used in 
> unexpected ways.
> 
> I could trick a golf course watering system to stop watering, increase the 
> flammability of the vegetation, and then use it to start an urban wildfire.

...or just wetten Donald Trump (Sorry, I couldn't resist)

Ulrich

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 1 Dec 2020 10:02:13 +0100

> we also want their data to be authenticated?

If it was easy and practical, maybe. But I suspect it would be
difficult to implement and not very practical. The corrections made by
network devices are expected to be smaller than what a MITM attacker
can generally do by delaying authenticated packets, so there is not
much of a point in authenticating the correction field.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 1 Dec 2020 10:05:41 +0100

> 2) it's difficult to set up and maintain

There might also be

4) the additional attack surface of the TLS/NTS implementation is
considered a bigger problem than not having secure timestamps.

-- 
Miroslav Lichvar

---

From: James <[email-masked]>
Date: Tue, 1 Dec 2020 10:20:48 +0100

> want to implement the complexity of NTS shouldn't be restricted to

Given that largest number of deployments of NTPv4 operate on public 
internet, if our intention is to have a protocol to supersede NTPv4 and 
solve the issues of those existing use cases, the protocol must provide 
mitigation to the existing threats of both server malfeasance and 
middlebox tampering and prevent downgrading that would enable either. 
NTS is not the only option and roughtime has shown it is possible to 
provide authentication primitives as a core part of the protocol without 
the larger overheads that a bolt-on requires.

- J

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 01 Dec 2020 10:22:59 +0100

>>> Miroslav Lichvar <[email-masked]> schrieb am 01.12.2020 um 09:44 in
Nachricht <20201201084448.GE1900232@localhost>:
>> Actually if you consider precision to be a "runtime value" (as opposed to a

> "design value") it's obvious that it is actually variable. However the  
> overhead to update the value was considered too heavy in NTP design, I
guess.
> timekeeping performance it is better to set the frequency to a

That's what I called "design" precision. However when you read the clock and
your computer is not fast enough for the full precision, should you work with
the full precision of the hardware or with the limited precision the software
can get? (Say your clock has 1ns resolution, but reading it takes 10 to 15 ns,
maybe even longer if there's high system load).

> 
>> > Using NTP short format the smallest non‑zero root dispersion is 15
>> Not just there: stability (clk_wander) could also need more digits. 
> clk_jitter is another candidate (it looks like a constant here for GPS). 
> Maybe more. Some are heritage of microsecond resolution of NTPv3.
> 

Agreed, but aren't they used internally? And are you saying we don't need
monitoring? ;-)

Regards,
Ulrich

> ‑‑

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 1 Dec 2020 10:37:26 +0100

On Tue, Dec 01, 2020 at 10:20:48AM +0100, James wrote:
> mitigation to the existing threats of both server malfeasance and middlebox
> tampering and prevent downgrading that would enable either.

Which security-related issues of existing use cases do you expect
NTPv5 to solve?

> NTS is not the
> only option and roughtime has shown it is possible to provide authentication
> primitives as a core part of the protocol without the larger overheads that
> a bolt-on requires.

Symmetric keys are not practical on public internet. If roughtime has
some significant advantages over NTS that would be useful in NTP,
there is nothing stopping us from specifying a roughtime extension for
NTP. I'm not sure why it would need to be included in the core protocol.

-- 
Miroslav Lichvar

---

From: "Dieter Sibold" <[email-masked]>
Date: Tue, 01 Dec 2020 10:51:22 +0100

> NTPv5, making it compatible with the NTS specification.

Yes, but this pre-shared key approach is not useable outside a closed 
group where the manual key management is feasible. In general you need 
to have an integrated key management like NTS.

> want to implement the complexity of NTS shouldn't be restricted to

Yes, I would propose that by default each NTP packet has to be 
authenticated. Not using security should be an active decision! I 
don’t think that security and increased time sync performance have to 
be orthogonal. The 2-step approach could provide better time sync 
performance and security.

>> Providing

Uncertainty and maximum error are different. The uncertainty interval 
will always be smaller or equal to the max. error.

> The smearing offset is provided in the Timescale Offset field.

Thanks.

---

From: Hal Murray <[email-masked]>
Date: Tue, 01 Dec 2020 01:54:46 -0800

[email-masked] said:
> (Say your clock has 1ns resolution, but reading it takes 10 to 15 ns, maybe
> even longer if there's high system load).

That 10 or 15 ns is a pipeline delay.  It's not directly related to the clock 
precision.

The typical clock on an Intel PC uses the TSC which ticks at the CPU clock 
frequency.  If your CPU is running at more than 1 GHz, then the clock will be 
good to better than 1 ns.

Here is a histogram of how long it takes to read the clock on a Raspberry Pi.
(Raspberry Pi 3 Model B running Fedora aarch64)
        ns      hits
        52    497520
        53     45070
       104    381437
       105     75962
       156         4
7 samples were bigger than 2551.

So the clock is ticking at somewhere between 2 and 53 ns.

You can read a clock that ticks slowly with (much) more precision that its 
nominal period.  The classic example is the TOY/CMOS battery backed clock that 
only ticks once a second.  If you spin until it ticks, you can get much closer 
than 1 second.  "Spin until" may not be convenient for most applications.

-- 
These are my opinions.  I hate spam.

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 1 Dec 2020 10:56:01 +0100

> maybe even longer if there's high system load).

If the clock takes a longer time to read due to high system load, that
delay will be included in the delay measured by the client. I think
the precision field should ideally describe the inherent precision
coming from the frequency in the hardware, i.e. how much information
there is actually in the timestamps provided by the server. That's
difficult to determine in userspace, so most implementations set the
precision to a minimum time it takes to read the clock. That's just an
upper bound on the actual precision. If it's a high-frequency clock
accessed over a slow bus, or there is a slow system call involved, it
can overestimate the precision by few orders of magnitude.

> Agreed, but aren't they used internally? And are you saying we don't need

I mean they are not relevant for the NTPv5 design. The monitoring
protocol should have its own specification.

-- 
Miroslav Lichvar

---

From: Hal Murray <[email-masked]>
Date: Tue, 01 Dec 2020 02:02:02 -0800

> So the clock is ticking at somewhere between 2 and 53 ns.

Oops.  I dropped a 5.  That should be "between 52 and 53 ns".

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 1 Dec 2020 11:03:05 +0100

On Tue, Dec 01, 2020 at 10:51:22AM +0100, Dieter Sibold wrote:
> authenticated. Not using security should be an active decision! I don’t
> think that security and increased time sync performance have to be
> orthogonal. The 2-step approach could provide better time sync performance
> and security.

Ok, so if the draft said something like "NTP clients SHOULD use
authentication", would that work for you? Ultimately, it would be up
to the client's default configuration whether authentication is
enabled or not.

> Uncertainty and maximum error are different. The uncertainty interval will
> always be smaller or equal to the max. error.

Can you describe an example how would the server determine the
uncertainty?

-- 
Miroslav Lichvar

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 1 Dec 2020 11:25:40 +0100

> Can you describe an example how would the server determine the

When talking about uncertainty, we talk about confidence interval.
We can never be sure what the maximum error is. We typically talk
about an expanded uncertainty of 95%, saying that in 95% of the
cases the error will be smaller than the uncertainty.

The 95% comes from 2 * sigma, which covers 95.45%. And we'll write
that as k=2 in case of a normal distribution. For NTP, in most
cases, it will not be a normal distribution, and you'll need a
different k factor for the 95%.

Kurt

---

From: Hal Murray <[email-masked]>
Date: Tue, 01 Dec 2020 02:40:40 -0800

[email-masked] said:
> authentication", would that work for you? Ultimately, it would be up to the
> client's default configuration whether authentication is enabled or not. 

That doesn't sound right to me.

You can't say SHOULD for something that is hard to implement.  In particular, 
authentication doesn't work with the pool.  For that SHOULD to make sense, we 
either have to add authentication to the pool or we have to put the pool out 
of business.

You can say something like "implementations SHOULD support authentication".  
It probably takes a paragraph to explain what that means and why we think it 
is a good idea.  But in reality, the basic protocol is so simple that people 
will throw together their own implementation, probably by reading stuff from 
the web rather than the actual RFC.

I think there is a chicken-egg problem.  Yesterday, authentication was hard to 
setup.  With NTS, it should be easy to setup the client side.  Now we have to 
get some public servers that support NTS.  We need lots of them, not just a 
few.

As a starter, it would be nice if ISPs ran authenticated servers for their 
clients.  Cloud farms too.

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 01 Dec 2020 13:19:16 +0100

>>> Hal Murray <[email-masked]> schrieb am 01.12.2020 um 10:54 in
Nachricht <[email-masked]>:

> [email-masked]‑regensburg.de said:

Hi Hal!

Is that pure theory, or actual measurements? I mean you'll have to do either
memory-mapped I/O which won't be cached (hopefully), or you'll have to read I/O
ports. Or do you talk about something inside the CPU? If so that may have high
precision until the CPU goes to power saving or whatever.

> (Raspberry Pi 3 Model B running Fedora aarch64)

Where did you get that 2 from? Assuming your read delay is between 50 and
100ns most of the time, does it make any difference whether the clock's
precision is 1 or 5ns?

Regards,
Ulrich

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 01 Dec 2020 13:32:44 +0100

>>> Kurt Roeckx <[email-masked]> schrieb am 01.12.2020 um 11:25 in Nachricht
> different k factor for the 95%.

Hi!

Yes, but which? How to get the right number?

Regards,
Ulrich

---

From: Doug Arnold <[email-masked]>
Date: Tue, 1 Dec 2020 13:04:29 +0000

Here is another use case where secure NTP might not be needed.  All the traffic in the application, including ntp is protected by IPsec or MACsec.  Yes that add some delays, but for some applications that is okay.

Doug

On 12/1/20, 5:03 AM, "ntp on behalf of Miroslav Lichvar" <[email-masked] on behalf of [email-masked]> wrote:

    -- 
    Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 01 Dec 2020 14:46:17 +0100

>>> Hal Murray <[email-masked]> schrieb am 01.12.2020 um 11:40 in

> of business.

Authentication as it is now with autokey being dead. Symmetric keys won't work
for pools, but asymmetric would.

> I think there is a chicken‑egg problem.  Yesterday, authentication was hard

---

From: Hal Murray <[email-masked]>
Date: Tue, 01 Dec 2020 05:49:03 -0800

[email-masked] said:
> memory-mapped I/O which won't be cached (hopefully), or you'll have to read I/
> O ports. Or do you talk about something inside the CPU? If so that may have
> high precision until the CPU goes to power saving or whatever. 

Intel has an instruction, rdtsc, that reads the TSC register.  It counts 
cycles.  Early implementations had problems since it counted CPU cycles rather 
than counting at a constant rate.  Those have all been sorted out.  It takes a 
long time to read it.  I don't know the details of what happens on SMP systems.
  https://en.wikipedia.org/wiki/Time_Stamp_Counter

There is some shared memory.  vdso is the buzzword.  There is a man page.

If the shared memory has a time stamp, and a TSC reading for that time, and a 
scale factor that turns TSC ticks into nanoseconds, you can compute the time as
  (newTSC-oldTSC)*scale + base_time.
There is some interesting hacking required to maintain precision and avoid 
overflow and such.  (And more hacking to avoid a race condition when things 
get updated.)

The similar instruction on ARM is illegal in user mode unless you turn on a 
magic bit.  I have no idea why.  Maybe some kernel option turns it on by now.  
Or maybe it was MIPS.  ????

----------

> Where did you get that 2 from? Assuming your read delay is between 50 and

Typo.  It should be 52

> (Raspberry Pi 3 Model B running Fedora aarch64)

That clock steps by 52-53.  There are no hits between o-53 and 53-104 and 
105-156.

On an Intel, I see this histogram:
(i3-2120 CPU @ 3.30GHz)
        ns      hits
        19    489605
        20    412237
        21     62486
        22     35190
        23        63
        24        50
        25        55
        26        50
        27        57
        28        56

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 1 Dec 2020 13:59:10 +0000

I never said all.  What percentage of closed devices do you think there will be?  Compared to a couple-billion on the public internet.  Approximately zero percent?

---

From: Doug Arnold <[email-masked]>
Date: Tue, 1 Dec 2020 14:48:29 +0000

I think that ms level time from the public internet is well supported by ntpv4, I thought part of the purpose of ntpv5 is to support niche applications. 

Doug

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 1 Dec 2020 16:00:26 +0100

> Yes, but which? How to get the right number?

There are various documents that explain it to you. I suggest
reading something like EA-4-02, which has has many examples.

Kurt

---

From: Hal Murray <[email-masked]>
Date: Tue, 01 Dec 2020 10:36:46 -0800

[email-masked] said:
> Here is another use case where secure NTP might not be needed.  All the
> traffic in the application, including ntp is protected by IPsec or MACsec.
> Yes that add some delays, but for some applications that is okay. 

How does IPsec work?  Does setting up the working keys depend on time like the 
certificate checking for TLS does?

---

From: Doug Arnold <[email-masked]>
Date: Tue, 1 Dec 2020 19:32:03 +0000

The time and security startup problem is not rigorously solved.  However, I have talked with network operators who favor using IPsec for all traffic, and they are aware of the start up problem, but figure that they are paying attention when the network is started up, so they are okay with it.  Note: these are not public internet applications. 

Doug

On 12/1/20, 1:36 PM, "Hal Murray" <[email-masked]> wrote:

---

From: Watson Ladd <[email-masked]>
Date: Wed, 2 Dec 2020 21:44:04 -0800

Dear NTP WG,

AES-GCM and Poly1305 are linear. In order to adjust the timestamp in
one step, it suffices to line everything up so that the hardware can
compute the correction in the same cycle as the stamp by isolating the
stamp in one block of the CWC hash.

This won't work with HMAC.

Sincerely,
Watson Ladd

-- 
Astra mortemque praestare gradatim

---

From: Hal Murray <[email-masked]>
Date: Thu, 03 Dec 2020 00:08:42 -0800

[email-masked] said:
> AES-GCM and Poly1305 are linear. In order to adjust the timestamp in one
> step, it suffices to line everything up so that the hardware can compute the
> correction in the same cycle as the stamp by isolating the stamp in one block
> of the CWC hash.

I think I'm missing a critical step.  Who/where is doing this "adjusting"?

The whole point of authentication is to prevent MITM "adjustments".

The only place I can see where something like that would make sense would be 
at the transmit network chip.  Why can't it do the whole authentication?  (The 
transmit side has the key.  The receive side can do the adjustment in 
postprocessing software.)

---

From: Doug Arnold <[email-masked]>
Date: Thu, 3 Dec 2020 20:03:35 +0000

I see you were paying attention. Accuracy and security are a trade-off.  If you want on path timing support and security, then you either have to have a lot of secrets or a secret that a lot of nodes are in on.  Either way it is less secure than just NTS between a client and a server.  However, in a private network where someone wants microsecond level time transfer accuracy that might be a sensible trade-off.

This could be handled using a symmetric group key that authorized nodes get periodically from a key exchange server.  See, for example GDOI.  I believe that NTS could be adapted to group key operation as well.

Doug

On 12/3/20, 3:08 AM, "ntp on behalf of Hal Murray" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Hal Murray <[email-masked]>
Date: Thu, 03 Dec 2020 15:36:34 -0800

[email-masked] said:
> This could be handled using a symmetric group key that authorized nodes get
> periodically from a key exchange server.  See, for example GDOI.  I believe
> that NTS could be adapted to group key operation as well. 

The whole idea of patching an authenticated packet seems wrong.

How much effort has gone into investigating alternatives?

> I see you were paying attention. Accuracy and security are a trade-off.  If
> you want on path timing support and security, then you either have to have a
> lot of secrets or a secret that a lot of nodes are in on.  Either way it is
> less secure than just NTS between a client and a server.  However, in a
> private network where someone wants microsecond level time transfer accuracy
> that might be a sensible trade-off. 

That seems like a narrow market.  It's a private network.  They want 
authentication so they don't trust their network yet they do trust it enough 
to patch their authenticated packets.

---

From: Doug Arnold <[email-masked]>
Date: Fri, 4 Dec 2020 01:03:16 +0000

I think that the enterprise networks of financial institutions, broadcast companies and power grids all want security and on path support.  Maybe large data centers as well. Broadcast and power have already adopted ptp and will probably stick with that, but my interactions with people in finance and data centers suggest that some of them would prefer a more precise version of ntp.  Some companies in finance are already doing nonstandard sub microsecond "ntp."  That is hardware timestamped ntp packets, but with higher than normal message rates and different client algorithms.  

The ntp working group could decide ntpv5 can support on path corrections or security, but not both.  However, I suspect a lot of people would be disappointed. 

Doug

On 12/3/20, 6:36 PM, "Hal Murray" <[email-masked]> wrote:

---

From: James <[email-masked]>
Date: Fri, 4 Dec 2020 10:11:56 +0100

Speaking as someone in broadcast, whilst the industry has standardised 
on the use of PTP in a few places (AES67, SMPTE 2110, etc) there are use 
cases where NTP is used instead, particularly where PTP is either not 
feasible or simply overkill for the application. Many of those operate 
on less-trusted networks or public internet and thus would greatly 
benefit from NTPv5 having greater security.

I don't believe on-path corrections and security are completely 
exclusive capabilities, but there's a spectrum between having on-path 
connection with either limited or more complicated security, or greater 
security with limitations on what corrections can be applied. As part of 
the requirements for NTPv5 I think the working group should decide where 
in the metaphorical spectrum we should focus on.

- J

---

From: "Dieter Sibold" <[email-masked]>
Date: Fri, 04 Dec 2020 17:46:48 +0100

On 4 Dec 2020, at 10:11, James wrote:

> on the use of PTP in a few places (AES67, SMPTE 2110, etc) there are 
> use cases where NTP is used instead, particularly where PTP is either 
> not feasible or simply overkill for the application. Many of those 
> operate on less-trusted networks or public internet and thus would 
> greatly benefit from NTPv5 having greater security.
>
> connection with either limited or more complicated security, or 
> greater security with limitations on what corrections can be applied. 
> As part of the requirements for NTPv5 I think the working group should 
> decide where in the metaphorical spectrum we should focus on.
>
> - J
>

I agree. There seems to me that different people have different ideas on 
how NTPv5 should develop. I cannot remember that we had any real 
discussion on NTPv5’s objective in the WG. It seems to me that this is 
urgently needed.

Dieter

>> I think that the enterprise networks of financial institutions, 
>> broadcast companies and power grids all want security and on path 
>> support.  Maybe large data centers as well. Broadcast and power have 
>> already adopted ptp and will probably stick with that, but my 
>> interactions with people in finance and data centers suggest that 
>> some of them would prefer a more precise version of ntp.  Some 
>> companies in finance are already doing nonstandard sub microsecond 
>> "ntp."  That is hardware timestamped ntp packets, but with higher 
>> than normal message rates and different client algorithms.
>>
>> The ntp working group could decide ntpv5 can support on path 
>> corrections or security, but not both.  However, I suspect a lot of 
>> people would be disappointed.
>>
>> Doug
>>

---

From: "Dieter Sibold" <[email-masked]>
Date: Fri, 04 Dec 2020 17:58:16 +0100

On 1 Dec 2020, at 11:03, Miroslav Lichvar wrote:

>> don’t

No. From my point of view this is not explicit. I would prefer that the 
basic protocol incorporates security. That would allow to use security 
without thinking about which approach needs to be applied to accomplish 
that. For the experts there might be additional option like the 
pre-shared key approach to acknowledge very specific circumstances. But 
the normal NTP  user should be able to use a secured NTPv5 like using a 
https protected website.

Obviously the wg needs to discuss about the objectives of NTPv5. This 
could be done, e.g., by adding a section about NTPv5’s objectives to 
the draft. Additionally we could also start a separate document for 
that.

Greetings Dieter

>> will

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 7 Dec 2020 11:45:41 +0100

On Fri, Dec 04, 2020 at 05:58:16PM +0100, Dieter Sibold wrote:
> that. For the experts there might be additional option like the pre-shared
> key approach to acknowledge very specific circumstances. But the normal NTP
> user should be able to use a secured NTPv5 like using a https protected
> website.

Ok, I see your point, but I don't think it's a good idea. NTPv5 was
supposed to fix other issues. I don't remember anyone complaining that
NTPv4 can be used without authentication. That's a feature, not a bug.
It's up to the implementations and their default configurations to
enable authentication.

Web browsers still default to HTTP and how long does HTTPS exist?

NTS just become a thing. Forcing people to NTS by removing
unauthenticated NTP from NTPv5 won't work.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 7 Dec 2020 11:54:06 +0100

> The ntp working group could decide ntpv5 can support on path corrections or security, but not both.  However, I suspect a lot of people would be disappointed. 

Please don't forget that MITM attackers can delay packets and cause
larger errors in NTP measurements than unauthenticated corrections.
Not allowing switches to make unauthenticated corrections in
authenticated packets will not improve security.

-- 
Miroslav Lichvar

---

From: [email-masked]
Date: Mon, 7 Dec 2020 14:25:11 +0100

But having unauthenticated corrections just makes it easier for the attacker, because writing a false correction might be less effort than an actual delay attack.

-----"ntp" <[email-masked]> schrieb: -----

An: [email-masked]
Von: "Miroslav Lichvar"
Gesendet von: "ntp"
Datum: 07.12.2020 11:54
Betreff: Re: [Ntp] The trick to timestamp with authentication

--
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 7 Dec 2020 14:50:01 +0100

On Mon, Dec 07, 2020 at 02:25:11PM +0100, [email-masked] wrote:
>    But having unauthenticated corrections just makes it easier for the
>    attacker, because writing a false correction might be less effort than an
>    actual delay attack.

I'd say it is the opposite. Delaying a packet is not that difficult.
For example, you can generate traffic in order to increase queueing
delays in switches/routers.

In a MITM attack you need to prevent the original packet sent by the
client or server reaching the other host. If you can do that, is it
easier to sent a modified packet than just waiting a bit before
sending the captured packet unmodified? I don't think there is a big
difference.

-- 
Miroslav Lichvar

---

From: "Dieter Sibold" <[email-masked]>
Date: Mon, 07 Dec 2020 15:52:13 +0100

But delaying may be easier to monitor since it increases the round trip 
delay, which is not the case if an correction field contains a forged 
timestamp.

Dieter

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 7 Dec 2020 15:09:15 +0000

>    Web browsers still default to HTTP and how long does HTTPS exist?

They are starting to move to "HTTPS first"  But yes, it took a long time.  There are other reasons, not particularly relevant to NTP tho.

We're not forcing anyone.  Folks who want unauthenticated NTP can stay on NTPv4.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 7 Dec 2020 16:34:44 +0100

> We're not forcing anyone.  Folks who want unauthenticated NTP can stay on NTPv4.

None of the issues that have been proposed for fixing in NTPv5 are
related to authentication. Why should folks interested in NTPv5 be
forced to use/implement authentication if they are perfectly ok with
unsecured NTP?

If you feel NTP needs a new name for "secure NTP", specify NTPS in a
separate document. You can apply it to NTPv5, NTPv4 and even NTPv3 if
you allow authentication with a symmetric key. This has nothing to do
with NTPv5 specifically.

-- 
Miroslav Lichvar

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 7 Dec 2020 16:38:43 +0000

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.

Does someone want to ask the current IESG for their view?

---

From: James <[email-masked]>
Date: Mon, 7 Dec 2020 17:57:28 +0100

I'm also interested in NTPv5. Based on my current use cases, the 
protocol having downgrade-resistant authentication as a core function of 
the protocol would simplify my deployments and improve the overall 
security of them and that deploying extensions, IPSec or other measures 
increase risk and complexity. Other use cases I have outlined[1] may 
also benefit as well. As an example, consider that several issues[2] (#5 
and #8) focus around the use of IP addresses in refid - if the 
identifier for a server was replaced with a identifier tied to a 
certificate or signature that was used as part of negotiating the 
primitives to provide authentication, this could theoretically address both.

As for your comment earlier around browsers defaulting to HTTP not 
HTTPS, consider that many browsers only support HTTP/2 with TLS and not 
"h2c", and that HTTP/3 requires QUIC (thus requiring TLS exclusively) - 
if implementations and deployments wish not to use TLS with HTTP, their 
only choice is to use older versions of the protocol.

- J

1: 
https://tools.ietf.org/html/draft-gruessing-ntp-ntpv5-requirements-00#section-2

2: https://trac.ietf.org/trac/ntp/wiki/NtpVersionFourIssues

---

From: Warner Losh <[email-masked]>
Date: Mon, 7 Dec 2020 10:28:55 -0700

On Mon, Dec 7, 2020 at 9:38 AM Salz, Rich <rsalz=[email-masked]>
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.
>

Time is harder, though, because most 'easy' authentication like https has a
time-element. If you don't yet know what time it is, it's hard to trust the
answers you get back if certificates are valid for only a given time and
some expired certificates have been compromised... But who doesn't like a
challenge... :)

BTW, I don't disagree. I'd love for there to be a good, authenticated time
infrastructure that included robust distribution of things like full leap
second history (and future) as a first class citizen, not a bolt-on like it
is today... But much of that info need not be at the lowest-level time
authentication bootstrapping since there's overlap with other areas and
services (the tz database, for example).

Warner

---

From: Philip Prindeville <[email-masked]>
Date: Mon, 7 Dec 2020 11:09:45 -0700

> On Dec 7, 2020, at 3:45 AM, Miroslav Lichvar <[email-masked]> wrote:
> 

HTTP isn’t by definition used to control infrastructure, and when it is used that way, HTTPS is usually mandated.

V4 goes back to 2010, but as I remember it was in use as protocol for a while before the implementation was written up and standardized.

And there were fewer known exploits then than now.

-Philip

---

From: Philip Prindeville <[email-masked]>
Date: Mon, 7 Dec 2020 11:17:10 -0700

> On Dec 7, 2020, at 6:50 AM, Miroslav Lichvar <[email-masked]> wrote:
> 

Such an attack would be much more likely to have a widespread impact, and hence more detectable.

---

From: Hal Murray <[email-masked]>
Date: Mon, 07 Dec 2020 13:19:58 -0800

> integrity and that people who disagree are out of consensus.

That seems like a good general principle, but doesn't seen to fit this example 
very well.

What do you mean by "has no authentication"?  Do you mean supports 
authentication or requires it?  I'll agree if you mean supports, but I assume 
you mean requires since otherwise we wouldn't be having this discussion.

Assuming you do mean requires, I'll pay a lot more attention to your argument if you outline a plan for getting the existing user base to demand authenticated time.

The complexity ratio between a simple non-authenticated NTP client and a client with authentication is enormous.

With HTTP to HTTPS, there was a lot of incentive for users and servers to upgrade.  Many did financial transactions over the web.  What's the equivalent for NTP?

---------

There is also an interesting operational side.  Authentication is only useful if you trust the authenticator.  I haven't seen any proposals for how the pool would support that layer of trust.

If you want the net to use authenticated time, I think you have to set up and run something similar to the root DNS servers -- that is a group of trusted people/organizations to run NTP servers that is large enough to support the load.

---

From: Hal Murray <[email-masked]>
Date: Mon, 07 Dec 2020 13:31:03 -0800

[email-masked] said:
> I'm also interested in NTPv5. Based on my current use cases, the  protocol
> having downgrade-resistant authentication as a core function of  the protocol
> ...

I don't think there will be anything in the protocol that requires 
downgrading.  There might be opportunities depending on server implementation 
details.  They might be there with or without words in an RFC.  The client can 
easily ignore them.

I think a paragraph mentioning downgrading would fit well in the Security 
section of an RFC.

---

From: Philip Prindeville <[email-masked]>
Date: Mon, 7 Dec 2020 14:36:14 -0700

> On Dec 7, 2020, at 2:19 PM, Hal Murray <[email-masked]> wrote:
> 
> 
> Salz, Rich said:

The 3 principles of Security are CIA: Confidentiality, Integrity, Availability.

How do these apply to NTPv5?  Some examples:

Confidentiality might be making client/server or peering connections unlinked outside of the (binary) relationship.  That was one of the issues with NTPv4; you could query a client to see what server it was talking to, and then spoof that server.

Integrity is protection from mangling packets in-flight, i.e. MITM attacks.  It might also be a chain-of-trust for time source hierarchy going back to a well-known (and explicitly trusted) group of servers who are authentic, which is often called “data pedigree”.

Availability is what it sounds like: the resilience of the service to interruptions, either by being resistant to denial-of-service attacks and single-point-of-failure disruptions, to geographical disruption to harden against network partitioning failures, to simplicity of correct configuration out-of-the-box, etc.

One of the golden objectives of security is “secure by default”: that is, things should be secure as installed by default, and it takes willful action by the administrator or user to explicitly disable this (aka “let him hang himself”).  I don’t see a reason for us to abandon this ideal.

"The complexity ratio between a simple non-authenticated NTP client and a client with authentication is enormous.”

What are you basing that assertion on?

And what about the flip-side of that argument?  What is the opportunity cost of not having that?  Where else does the mitigation end up instead?  Firewalling?  Sanity checking clocks against multiple sources?  Inability to have boot-time PKI integrity because of not being able to check X.509 validity intervals (and the obvious ripple-effect of PKI through other services)?

---

From: Doug Arnold <[email-masked]>
Date: Mon, 7 Dec 2020 22:10:05 +0000

I think that we all agree that ntpv5 has to have a security mechanism,  but it could be optional and/or described in a separate document.  Time over the open internet is a popular use case, and it must be covered.  But there is a lot of ntp in private networks.  Many network operators in these networks will want to turn on security, but probably not all.

Doug

On 12/7/20, 11:38 AM, "ntp on behalf of Salz, Rich" <[email-masked] on behalf of rsalz=[email-masked]> wrote:

---

From: Doug Arnold <[email-masked]>
Date: Mon, 7 Dec 2020 22:18:53 +0000

Some of the niche applications for ntp that we are enabling by separating the algorithms and protocol are the ones that won't want security.  I don't have a problem with security that is turned on by default.  And no security is recommended only for unusual cases such timing in a cyber physical system not attached to the internet.

Doug

---

From: Philip Prindeville <[email-masked]>
Date: Mon, 7 Dec 2020 15:25:50 -0700

If you’re saying “we all agree […] it could be optional” then I dissent.

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.

One of my previous employers (Gigamon) built an entire business model on the assumption that you need to monitor internal traffic for malware, insider attacks, etc. and hence marketed “network visibility appliances” (i.e. switches and taps that could intercept traffic and clone it to an IDS for real-time analysis).  The market apparently agrees.

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 Dec 7, 2020, at 3:10 PM, Doug Arnold <[email-masked]> wrote:
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 7 Dec 2020 22:34:54 +0000

>    Assuming you do mean requires, I'll pay a lot more attention to your argument if you outline a plan for getting the existing user base to demand authenticated time.

NTPv5, a new version of the NTP protocol, will include authenticated servers. NTPv5 clients will also be able to detect if server messages were modified in-transit.

NTPv5 is the carrot, or the stick, depending on how you want to look at it.

---

From: Hal Murray <[email-masked]>
Date: Mon, 07 Dec 2020 15:03:54 -0800

[email-masked] said:
>>    Assuming you do mean requires, I'll pay a lot more attention to your
>> argument if you outline a plan for getting the existing user base to demand
>> authenticated time.

> NTPv5, a new version of the NTP protocol, will include authenticated servers.
> NTPv5 clients will also be able to detect if server messages were modified
> in-transit.

> NTPv5 is the carrot, or the stick, depending on how you want to look at it. 

Why will NTPv5 be more interesting than NTPv4+NTS which is already available?

---

From: Hal Murray <[email-masked]>
Date: Mon, 07 Dec 2020 16:28:24 -0800

[email-masked] said:
> One of the golden objectives of security is “secure by default”: that is,
> things should be secure as installed by default, and it takes willful action
> by the administrator or user to explicitly disable this (aka “let him hang
> himself”).  I don’t see a reason for us to abandon this ideal.

That seems like a fine goal, but it doesn't require that the protocol enforce 
authentication.

> What are you basing that assertion on?

Having written lots of code.

What do you really want to know?  Are we quibbling about my use of "enormous"?

wc says the NTS code in ntpsec is 2666 lines.  (That includes the server side 
but not the header files.)  That drags in the OpenSSL libraries and Daniel 
Frank's libaes_siv.

The old joke is that you can fit anything on a single page if you use a small 
enough font.  If it will help the discussion, I'll write a minimal NTP client. 
 I don't think it will fit on a single page, but it won't be very big.

> And what about the flip-side of that argument?  What is the opportunity cost
> of not having that?  Where else does the mitigation end up instead?
> Firewalling?  Sanity checking clocks against multiple sources?  Inability to
> have boot-time PKI integrity because of not being able to check X.509
> validity intervals (and the obvious ripple-effect of PKI through other
> services)? 

I'm all for NTPv5 supporting authentication, but I don't think it should be 
mandatory.

Should we start a new thread about the infrastructure it will take to support 
universal authenticated time and how we are going to get it?

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 8 Dec 2020 01:27:12 +0000

>    Why will NTPv5 be more interesting than NTPv4+NTS which is already available?

Don't know what's in NTPv5 yet.

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 08 Dec 2020 10:10:22 +0100

>>> "Salz, Rich" <rsalz=[email-masked]> schrieb am 07.12.2020 um 16:09
in Nachricht <[email-masked]>:
> They are starting to move to "HTTPS first"  But yes, it took a long time.  
> There are other reasons, not particularly relevant to NTP tho.
> 

I also would disagree: If NTPv5 favors authentication it could be on by default, but it's not OK to make it impossible to use unauthenticated packets. It could be done in the next version v6) if needed. A transition phase MUST be provided IMHO.

Regards,
Ulrich

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 08 Dec 2020 10:13:49 +0100

>>> "Salz, Rich" <rsalz=[email-masked]> schrieb am 07.12.2020 um 17:38
> integrity and that people who disagree are out of consensus.

I agree to disagree: NTPv5 is not a new protocol design; it's the next generation of an established protocol.
If NTPv5 is strictly authenticated, the any NTPv5 server MUST support the NTPv4 protocol.

But I think it would be a poor choice as NTPv4 has problems and the NTPv5 world would be a "closed world" so it would not spread fast for compatibility reasons.

Regards,
Ulrich

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 08 Dec 2020 10:43:53 +0100

>>> Philip Prindeville <[email-masked]> schrieb am 07.12.2020 um
22:36 in Nachricht
<[email-masked]>:

>> With HTTP to HTTPS, there was a lot of incentive for users and servers to 
> upgrade.  Many did financial transactions over the web.  What's the 
> equivalent for NTP?
> 
> 

Hi!

OK, how about starting to build a "CIA table" listing for each NTP variable whether it needs C, I, or A?
I think such a table would be a gouud base for further discussion.
Initially I would thing the current time does not have to be confidential, unless you deliberatly want to run on wrong time...

Regards,
Ulrich
[...]

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 08 Dec 2020 10:50:35 +0100

>>> Philip Prindeville <[email-masked]> schrieb am 07.12.2020
um
23:25 in Nachricht
<[email-masked]>:
> 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.
> 
> One of my previous employers (Gigamon) built an entire business model on the

> assumption that you need to monitor internal traffic for malware, insider 
> attacks, etc. and hence marketed “network visibility appliances” (i.e. 
> switches and taps that could intercept traffic and clone it to an IDS for 
> real-time analysis).  The market apparently agrees.
> 
> 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.

I think the bigger problem is some trojan sent from external having access to
the internal (unsecured) network.
Most employees have to sign that they don't do evil things and they don't
publish confidential information, so I don't see insiders being that evil, but
theere may be bosses using that argument to monitor what their emplyees do
(which may be illegal just the same way...).

Regards,
Ulrich

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 8 Dec 2020 10:50:46 +0100

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

The NTPv5 draft does supports authentication. It is exactly the same
as in NTPv4. The message format is extensible. Multiple authentication
mechanisms can be supported. If NTS is found to be insecure or
something better comes along, it can be used in NTPv5. No need to
specify a new NTP protocol.

To me it sounds like some people here think that's a bad thing and
want NTPv5 to have NTS baked in or add some artificial restrictions to
make unauthenticated messages syntactically invalid. That makes no
sense to me.

If you propose something, there should be a technical explanation
provided.

-- 
Miroslav Lichvar

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 8 Dec 2020 14:20:47 +0000

provided.

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.

I am leaving it vague so that the WG can figure things out.

---

From: Marcus Dansarie <[email-masked]>
Date: Tue, 8 Dec 2020 15:50:00 +0100

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

/Marcus

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 8 Dec 2020 16:07:25 +0100

> I am leaving it vague so that the WG can figure things out.

As others explained, that is a difficult problem. A feeling about what
is acceptable is not helping if you don't have a solution. NTS relying
on TLS is the best thing we have now. If it has a 50% share of global
NTP in 2030, I think it will be a great success. Currently it is 0%.

We have identified NTPv4 issues that we want to have relatively
quickly fixed in NTPv5. If someone figures out solution that will make
authenticated NTP universally usable, it can be adopted by NTPv4, v5,
or whatever version exists at the time. This effort should be separate
from NTPv5.

-- 
Miroslav Lichvar

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 8 Dec 2020 15:13:28 +0000

>    As others explained, that is a difficult problem.

Yes it is tricky.  Fortunately, there are people and groups with crypto expertise available to us.

> A feeling about what
    is acceptable is not helping if you don't have a solution.

Sure, we call this gathering requirements.

I am not sure that I have anything new to add here.  At some point we'll have to determine consensus, but so far this thread has had a limited number of participants.

---

From: James <[email-masked]>
Date: Tue, 8 Dec 2020 16:51:21 +0100

Given so many existing deployments end up running for many, many years 
the next version of NTP will also be around for a long time. Extensions 
and bolt-ons alone will not suffice in assuring the protocol's 
longevity, and that there is clearly a lot of work that must be done 
with the core of the protocol to address ossification, agility, as well 
as security. I would rather see NTPv5 solve these issues and take longer 
in its design than just deal with the "quick fixes", and I'm prepared to 
invest a significant portion of my own time and energy to support the 
efforts.

- J

---

From: Magnus Danielson <[email-masked]>
Date: Tue, 8 Dec 2020 16:53:15 +0100

Marcus,

> 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

---

From: Warner Losh <[email-masked]>
Date: Tue, 8 Dec 2020 13:11:46 -0700

Magnus,

> upgrade to ensure correct leap-second list that way.

When I implemented the LORAN-C timing system refresh at Timing Solutions,
this issue was the biggest issue we had. We could get leap seconds from the
GPS, and had to resort to a number of ad-hoc methods to distribute from
there. Especially since we needed to cope with the scenario where a
computer fails and is replaced by a spare that had been on the shelf for 5
years, but still had the requirement it couldn't get setting the UTC time
of the atomic clock wrong (since LORAN TOC was timed vs UTC time scale, so
a wrong time meant wrong timing signals to the LORAN transmitter), nor wait
for a full GPS almanac to download.... We used a number of ad-hoc methods
to do this since there was nothing standard and in practice they proved to
be less robust than one would have liked. These machines were networked,
but on a private network that existed at each LORAN station only with only
minimal connectivity to the outside world (if any).

Leap seconds sound easy and simple, but the logistical issues surrounding
them are legend, especially when one must engineer for discontinuous use
cases.

Leap seconds are trivial if you have perfect knowledge. Sadly, history has
shown that this knowledge to be somewhat less than perfect...

Warner

---

From: Magnus Danielson <[email-masked]>
Date: Wed, 9 Dec 2020 00:43:45 +0100

Warner,

On 2020-12-08 21:11, Warner Losh wrote:
> Magnus,
>
> On Tue, Dec 8, 2020 at 8:53 AM Magnus Danielson <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> When I implemented the LORAN-C timing system refresh at Timing
> Solutions, this issue was the biggest issue we had. We could get leap
> seconds from the GPS, and had to resort to a number of ad-hoc methods
> to distribute from there. Especially since we needed to cope with the
> scenario where a computer fails and is replaced by a spare that had
> been on the shelf for 5 years, but still had the requirement it
> couldn't get setting the UTC time of the atomic clock wrong (since
> LORAN TOC was timed vs UTC time scale, so a wrong time meant wrong
> timing signals to the LORAN transmitter), nor wait for a full GPS
> almanac to download.... We used a number of ad-hoc methods to do this
> since there was nothing standard and in practice they proved to be
> less robust than one would have liked. These machines were networked,
> but on a private network that existed at each LORAN station only with
> only minimal connectivity to the outside world (if any).
>
> Leap seconds sound easy and simple, but the logistical issues
> surrounding them are legend, especially when one must engineer for
> discontinuous use cases.
>
> Leap seconds are trivial if you have perfect knowledge. Sadly, history
> has shown that this knowledge to be somewhat less than perfect...

It's not only that, but also depends on over what system they are
conveyed over. Some work better than others. Some show for sure that
they where not designed with leap-second handling up-front, and the
patch work create various pains. As we look forward for NTP for
instance, we should make sure that the leap-second difference and
related mechanisms goes in with it up front.

As I've done work recently in a related effort, I've found that while
operating system may have needed capabilities, knowledge of what comes
in the box as well as configure it up properly to build a capable system
remains the challenge. What we can learn is to make sure that we remove
as much as possible of detailed configurations to make it work properly,
but make it the default behavior needing minimal configuration that
works. As you step the major version, you are allowed to break some old
behaviors in order to establish new default behavior.

Once TAI, UTC, GPS, PTP or NTP time is known alongside the leap-second
info, producing the other time-scales is fairly simple and
straight-forward, including leap-second steps. What keeps confusing
people is that UNIX and Linux time-scales jump differently.

The only IRIG-B version I've seen that do leap-second handling fairly
well is that of the IEEE C37.118.1 variant. Several of the IRIG variants
is not even close to do leap-second handling very well. The power-grid
folks is very aware of it and testing has been done to improve the
situation. That remains the key point, sufficient support and testing.

Cheers,
Magnus

---

From: Watson Ladd <[email-masked]>
Date: Tue, 8 Dec 2020 20:22:14 -0800

To clarify, I was solely suggesting this as a solution to the problem
of a transmit timestamp computed on the network card, not for
intermediate corrections, where the security tradeoffs are more dire.

Sincerely,
Watson Ladd

---

From: Warner Losh <[email-masked]>
Date: Tue, 8 Dec 2020 22:29:58 -0700

On Tue, Dec 8, 2020 at 4:43 PM Magnus Danielson <[email-masked]> wrote:

> It's not only that, but also depends on over what system they are conveyed
> over. Some work better than others. Some show for sure that they where not
> designed with leap-second handling up-front, and the patch work create
> various pains. As we look forward for NTP for instance, we should make sure
> that the leap-second difference and related mechanisms goes in with it up
> front.
>
> operating system may have needed capabilities, knowledge of what comes in
> the box as well as configure it up properly to build a capable system
> remains the challenge. What we can learn is to make sure that we remove as
> much as possible of detailed configurations to make it work properly, but
> make it the default behavior needing minimal configuration that works. As
> you step the major version, you are allowed to break some old behaviors in
> order to establish new default behavior.
>
I'd love that. Too few things care to get leap seconds right, leading to
the balkanization of efforts and generally a dog's breakfast of what works
and what doesn't. Bravo!

> straight-forward, including leap-second steps. What keeps confusing people
> is that UNIX and Linux time-scales jump differently.
>

Yea, you need both. It's thinking you can get by with only one if you can't
quickly lay hands on the other. It's the last bit I ran into trouble with,
even though the systems I worked on were redundant, sharing that
information in a pinch was a pain. Whose copy was right, what to do when
they disagreed etc got off into the weeds quickly...

The only IRIG-B version I've seen that do leap-second handling fairly well
> is that of the IEEE C37.118.1 variant. Several of the IRIG variants is not
> even close to do leap-second handling very well. The power-grid folks is
> very aware of it and testing has been done to improve the situation. That
> remains the key point, sufficient support and testing.
>
Yes. I've only ever seen it in an ancient product at Timing Solutions that
seemed to either be a one-off or a checklist item since it never seemed to
work and even if it did long term clients didn't get enough warning because
the lead time was < 1000 seconds...

 Warner

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 09 Dec 2020 08:17:51 +0100

>>> James <[email-masked]> schrieb am 08.12.2020 um 16:51 in Nachricht
<[email-masked]>:
> and bolt‑ons alone will not suffice in assuring the protocol's 

I agree: Most "quick fixes" from the past have lead to long lasting grief in
the future. Autokey being one example?

> 
> ‑ J
> 
> On 08‑12‑2020 15:07, Miroslav Lichvar 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.
>>>

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 9 Dec 2020 09:38:00 +0100

On Tue, Dec 08, 2020 at 04:51:21PM +0100, James wrote:
> Given so many existing deployments end up running for many, many years the
> next version of NTP will also be around for a long time. Extensions and
> bolt-ons alone will not suffice in assuring the protocol's longevity, and
> that there is clearly a lot of work that must be done with the core of the
> protocol to address ossification, agility, as well as security. I would
> rather see NTPv5 solve these issues and take longer in its design than just
> deal with the "quick fixes", and I'm prepared to invest a significant
> portion of my own time and energy to support the efforts.

How do you know that extensions will not suffice? Maybe it's clear to
you and others, but not to me. Can you please explain in more detail
why the core protocol needs to be changed?

To me, NTP is a protocol for exchanging timestamps and some related
metadata over network. Compared to most other protocols it's extremely
simple. The data can be authenticated or not. For NTP, it doesn't
matter how it is authenticated. Either the mechanism requires prior
knowledge of time, or it does not. NTP cannot help you to circumvent
that requirement.

What do you want NTP to do?

The issues we have on the wiki are long known, understood and have
proposed fixes. They are causing issues in existing applications. If
there is not much bikeshedding, we can have a complete NTPv5 draft in
couple months. Implementations can follow and people are happy.

Now, suddenly people talk about some non-specific issues that have an
unknown solution. Where were you when NTS was designed? And why does
it need to be solved in NTPv5?

-- 
Miroslav Lichvar

---

From: Magnus Danielson <[email-masked]>
Date: Wed, 9 Dec 2020 13:26:28 +0100

Warner,

On 2020-12-09 06:29, Warner Losh wrote:
>
>
> On Tue, Dec 8, 2020 at 4:43 PM Magnus Danielson <[email-masked]
>>     On Tue, Dec 8, 2020 at 8:53 AM Magnus Danielson
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Solutions, this issue was the biggest issue we had. We could get
>>     leap seconds from the GPS, and had to resort to a number of
>>     ad-hoc methods to distribute from there. Especially since we
>>     needed to cope with the scenario where a computer fails and is
>>     replaced by a spare that had been on the shelf for 5 years, but
>>     still had the requirement it couldn't get setting the UTC time of
>>     the atomic clock wrong (since LORAN TOC was timed vs UTC time
>>     scale, so a wrong time meant wrong timing signals to the LORAN
>>     transmitter), nor wait for a full GPS almanac to download.... We
>>     used a number of ad-hoc methods to do this since there was
>>     nothing standard and in practice they proved to be less robust
>>     than one would have liked. These machines were networked, but on
>>     a private network that existed at each LORAN station only with
>>     surrounding them are legend, especially when one must engineer
>>     for discontinuous use cases.
>>
>>     Leap seconds are trivial if you have perfect knowledge. Sadly,
>>     history has shown that this knowledge to be somewhat less than
>>     perfect...
>
>     conveyed over. Some work better than others. Some show for sure
>     that they where not designed with leap-second handling up-front,
>     and the patch work create various pains. As we look forward for
>     NTP for instance, we should make sure that the leap-second
>     difference and related mechanisms goes in with it up front.
>
>     As I've done work recently in a related effort, I've found that
>     while operating system may have needed capabilities, knowledge of
>     what comes in the box as well as configure it up properly to build
>     a capable system remains the challenge. What we can learn is to
>     make sure that we remove as much as possible of detailed
>     configurations to make it work properly, but make it the default
>     behavior needing minimal configuration that works. As you step the
>     major version, you are allowed to break some old behaviors in
> I'd love that. Too few things care to get leap seconds right, leading
> to the balkanization of efforts and generally a dog's breakfast of
> what works and what doesn't. Bravo!

Thanks.

So, if you look at Linux today, you do have the NTP nano-kernel support,
you have POSIX support for monotonic clock as well as TAI clock. You can
get the TAI-UTC leap-second difference in and out of the kernel over the
nano-kernel interface. The code in the kernel is able to do the
leap-second. What remains for us to do is to make sure we provide the
leap-second information to it, and then for other applications they
request time such that they get the needed leap-second information. This
is not as much a technology issue as much as documentation and
educational issue. Long gone is the time when I needed to patch the
kernel up and recompile it and stuff like that.

The technology support we could potentially potentially need that libc
would read out the TAI-UTC difference and output the right format of
time as result. The needed logic isn't all that hard. From there there
is a ripple effect, but not too hard.

The one thing to fix in NTP is that the TAI-UTC leap-second difference
should never have been made tied so hard to the authentication mechanism
as it was. It was actually three components in the same RFC, the
authentication, the NTP extension field mechanism and the TAI-UTC
leap-second extension. As the authentication was being thrown out, so
was the extension field mechanism and the TAI-UTC leap-second extension.
I did see a draft for saving the extension field mechanism, and I think
it ended up as RFC, but the TAI-UTC leap-second extension I can't recall
being "saved".

We need to ensure we maintain the TAI-UTC leap-second extension and I
would even prefer if it became a mandatory component as we go forward,
as I see it as a crucial component. Systems such as UTC and PTP provide
it, and it is a game-changer in being able to properly handle things.
The prewarning system approach to a step helps, and actually is needed
in parallel for best function as repeatedly demonstrated, but ends up
being vulnerable to corner cases.

I would make sure that a future NTPv5 for sure has the TAI-UTC
leap-second extension included.

We can improve the state of things by documentation, potentially as a
informational RFC, best current practices for how systems and
implementations to handle time-scales. I've even found such RFCs that to
some degree is misleading, so in the process providing an update for
that RFC may be a side-consequence.

>     Once TAI, UTC, GPS, PTP or NTP time is known alongside the
>     leap-second info, producing the other time-scales is fairly simple
>     and straight-forward, including leap-second steps. What keeps
>     confusing people is that UNIX and Linux time-scales jump differently.
>
>
> Yea, you need both. It's thinking you can get by with only one if you
> can't quickly lay hands on the other. It's the last bit I ran into
> trouble with, even though the systems I worked on were redundant,
> sharing that information in a pinch was a pain. Whose copy was right,
> what to do when they disagreed etc got off into the weeds quickly...

Yes, that is exactly my experience too. Essentially when you are caught
with the moment of surprise it will be hard to backtrack nicely and this
only comes down to not having prewarning and proper offset values
available. If you have those values, it's not too hard.

Another thing which keeps confusing people is that they think UNIX or
POSIX clock behavior also applies to Linux clock, and it doesn't, so
they have different leap-second behavior, but if you have the
information in advance and know how they behave, properly traversing the
leap-second becomes fairly dull algebra.

I made a small piece of code (attached for whoever is interested) that
outputs this:

ntp 3692217598 ptp 1483228834 gps 1167264015 tai 00:00:34 utc 23:59:58
gps 00:00:15 unix 23:59:58 linux 23:59:58 tai-utc 36 leapsec 0
tai-utc(post) 36
ntp 3692217599 ptp 1483228835 gps 1167264016 tai 00:00:35 utc 23:59:59
gps 00:00:16 unix 23:59:59 linux 23:59:59 tai-utc 36 leapsec 0
tai-utc(post) 36
ntp 3692217600 ptp 1483228836 gps 1167264017 tai 00:00:36 utc 23:59:60
gps 00:00:17 unix 00:00:00 linux 23:59:59 tai-utc 37 leapsec 1
tai-utc(post) 36
ntp 3692217600 ptp 1483228837 gps 1167264018 tai 00:00:37 utc 00:00:00
gps 00:00:18 unix 00:00:00 linux 00:00:00 tai-utc 37 leapsec 0
tai-utc(post) 37
ntp 3692217601 ptp 1483228838 gps 1167264019 tai 00:00:38 utc 00:00:01
gps 00:00:19 unix 00:00:01 linux 00:00:01 tai-utc 37 leapsec 0
tai-utc(post) 37

Building on a number of relationships. In the process, I found that
there was an unfortunate wording in the NIST leapsecond file, and Judah
Levine thanked me for the observation and said he would adjust wording
for the next update. The issue is that one needs to understand it as
being related to NTP context and thus the behavior of NTP time-stamp.

Some useful relationships is found in the leapsecond file, some in the
NTP documentation and books, some in the IEEE Std 1588 definition and
annex B. This scattered set of references may need to be collected at
some more proper place.

>
>     The only IRIG-B version I've seen that do leap-second handling
>     fairly well is that of the IEEE C37.118.1 variant. Several of the
>     IRIG variants is not even close to do leap-second handling very
>     well. The power-grid folks is very aware of it and testing has
>     been done to improve the situation. That remains the key point,
>     sufficient support and testing.
>
> Yes. I've only ever seen it in an ancient product at Timing Solutions
> that seemed to either be a one-off or a checklist item since it never
> seemed to work and even if it did long term clients didn't get enough
> warning because the lead time was < 1000 seconds...

The IEEE C37.118.1 provides an extension that provides the prewarning
mechanism and local clock offset, which is much more helpful than
suddenly finding yourself with the time of 23:59:60 (unknown local clock
offset) or 00:00:60 (unknown local clock offset) to get a pre-warning
(albeit not with huge time before) that there is an upcoming leap-second
and with +1.00 hour local time-offset you can expect the 00:00:60+1:00
to occur and also get information that this second is this leap-second
event. It's needed because as you measure phase and time-stamp phase of
power grid 50 or 60 Hz, just a tad of frequency offset of the grid and a
leap-second here and there will create false indication of massive phase
error. Those interested in evidence of that is recommended to check out
NASPI, and in particular the NASTP TSTF report from 2017 that I helped with.

So, while not perfect, it illustrates the importance of providing the
key information. IRIG-B has the other significant draw-back that the
time may, for regulatory or operational reasons, be set to the local
time rather than UTC, so one also needs to carry the local time offset
such that the underlying UTC time can be retrieved, but also to
indirectly follow the TAI as the phase-comparison is actually to TAI.
This goes to show just how an application can need to have all three
times, and how crutial the full support has become for a number of
applications.

I see in fact more and more applications where leap-second smearing is
creating worse problems than just address the leap-second problem
up-front and be done with it. This turns out to be just about the same
problem as when UTC was using frequency corrections prior to 1972, so we
end up suffering from the same basic problem.

The work I had to do was relating to the AES 67 standard and applicable
to WAN and also cloud environments. We concluded that strictly requiring
PTP access can not generally be assumed to be available, either because
the network is not able to convey PTP, which you cannot assume in a WAN
setting, or for that mater that the host environment is not able to
provide access to PTP, or similar time-service, which can exist in
mobile phone devices as well as in the virtual hosts in a cloud
environment. Thus, the need to indirect being able to access the PTP
time-scale through other means, as it forms the basis for the AES67
media clock. So, I ended up having to revisit this particular rabbit
hole. I think we can improve the state of things to guide people right,
and I think we can also learn from the real life challenges the things
we need to consider as we design these things and then document them
such that we quicker get people up to speed.

At the same time I notice that for each leap-second, the consequences
becomes smaller, bugs is being fixed, testing has improved.

Cheers,
Magnus

---

From: James <[email-masked]>
Date: Wed, 9 Dec 2020 15:12:52 +0100

My responses inline.

> why the core protocol needs to be changed?

I was hoping that the requirements document[1] I had briefly written, 
along with the several[2] emails I have sent to you and the list[3] 
describing more of my use cases and needs as well as those of others 
believed to be relevant would have sufficiently answered this question 
already. To summarise, I believe the core protocol needs to offer 
downgrade-resistant authentication as:

* Many existing NTPv4 deployments (including my own) operate on 
untrusted networks that have a risk and threat profile where packet 
filtering and manipulation is credible or occurring;

* Securing NTP via extensions, IPSec etc adds additional cost and 
integration complexity as well as an increased risk of downgrade or 
misconfiguration in deployments;

* And that the computation/latency costs that would incur would be 
acceptable and reduced as implementations improve over time.

> What do you want NTP to do?

The core function as you put of "exchanging timestamps and related 
metadata" is not being contested here.

What are the use cases you are considering, and what limitations do you 
think that providing authentication will impose on the protocol that 
would not make it suitable for them?

> it need to be solved in NTPv5?

I did not get involved with the IETF until mid 2018 which was towards 
the later part of it's design and I was focusing on other areas at the time.

- J

1: 
https://datatracker.ietf.org/doc/html/draft-gruessing-ntp-ntpv5-requirements/

2: https://mailarchive.ietf.org/arch/msg/ntp/l0P0p-Cl0WMDo6COZItFuwEkR1E/

3: https://mailarchive.ietf.org/arch/msg/ntp/uB4VnYTROSr2nCmEFa_J4IdeWLc/

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 9 Dec 2020 14:56:55 +0000

> it need to be solved in NTPv5?

NTS was designed to add security features to an existing protocol without disrupting it.

NTPv5 should be designed with security built-in from the beginning.

Miroslav's draft is just an individual viewpoint.  I would be against the WG adopting it because the author seems to be opposed to the design requirement I just mentioned.

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 9 Dec 2020 16:04:37 +0100

On Wed, Dec 09, 2020 at 03:12:52PM +0100, James wrote:
> I was hoping that the requirements document[1] I had briefly written, along
> with the several[2] emails I have sent to you and the list[3] describing
> more of my use cases and needs as well as those of others believed to be
> relevant would have sufficiently answered this question already.

I had read your draft (thanks for writing it!) and your emails, but
it's not clear to me. I thought my proposal was meeting the
requirements.

> To
> summarise, I believe the core protocol needs to offer downgrade-resistant
> authentication as:

Is NTPv4+NTS or the NTPv5 I'm proposing + NTS not resistant to
downgrade attacks? Are you refering to some TLS issue? What changes
would you suggest to fix it?

> misconfiguration in deployments;

I don't understand this part at all. An NTP authentication mechanism
in an extension field is very different from IPSec.

If NTP wasn't secured with an extension, how would it prevent
downgrade or misconfiguration? Are you considering a bug where the
client forgets to check if the packet is authenticated? Do you expect
NTP implementations to drop support for older NTP versions?

If it is not an extension, how do you replace it when it's found to be
insecure?

> acceptable and reduced as implementations improve over time.

It takes few microseconds to authenticate an NTP packet with NTS. Are
you saying that's too long? What is your use case? The delay is
comparable to the typical error of a transmit timestamp. In the
interleaved mode it doesn't matter how long it is, it's compensated.

> think that providing authentication will impose on the protocol that would
> not make it suitable for them?

I'm trying to consider all the use cases I've heard about. That
includes isolated networks and various hardware implementations with
different limitations, where it is not possible or not practical to
implement TLS/NTS.

Don't forget about pool.ntp.org. Do you not want NTPv5 to be supported
there?

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 9 Dec 2020 16:35:29 +0100

> NTPv5 should be designed with security built-in from the beginning.

That implies you think NTPv4+NTS has some security issues that could
be addressed in NTPv5. Unfortunately, I still don't understand what it
is.

> Miroslav's draft is just an individual viewpoint.  I would be against the WG adopting it because the author seems to be opposed to the design requirement I just mentioned.

That's ok. As I explained before, my proposal is an evolution of NTPv4
not trying to fix what's not broken. If I was designing it from
scratch, I don't think I'd get something radically different.

-- 
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 10 Dec 2020 08:23:05 +0100

>>> "Salz, Rich" <rsalz=[email-masked]> schrieb am 09.12.2020
um 15:56
in Nachricht <[email-masked]>:
>>  Now, suddenly people talk about some non‑specific issues that have an
> NTPv5 should be designed with security built‑in from the beginning.

I think "security" was "built-in" since NTPv3, but:
Was the security srong enough?
Was the security easy to deploy and use?
Did it need shared secrets between different authority zones?

In v4 autokey tried to address some issues, while adding several new

So what should v5 really bring?

Regards,
Ulrich

> 
> Miroslav's draft is just an individual viewpoint.  I would be against the WG

> adopting it because the author seems to be opposed to the design requirement

> I just mentioned.

---

From: [email-masked]
Date: Thu, 10 Dec 2020 11:38:41 +0100

It seems to me that the answer is clearly that NTPv5 should natively make available security that is strong (enough), as well as easy to deploy and use.

I do not agree with the train of thought that because some users don't strictly need security for their use case, security should be disabled by default.

1) First of all, this only makes abstract sense to me as a conclusion if security enabled by default comes at significant cost - and I think we can prevent this from being true, specifically by investing work into support of a "two-step" message format, where all security (and, honestly, most information overall) is only included in the "follow-up" message; then security being enabled really has zero extra cost (apart from everything being more accurate overall).

2) Second of all, I think these use cases (where users don't need security because they are using NTP in a closed controlled network) are the exception rather than the norm. The majority of NTP traffic is going to happen over the open internet, and security should pretty much unconditionally be used in that scenario.

As kind of an aside @Miroslav: I don't think anyone is claiming that NTPv4+NTS has a security issue in the sense that it does not provide adequate security when used (otherwise I really would like to explicitly hear such concerns!).

I think people are saying that NTPv4 with *available* NTS provides too much leeway to not use security.

Most importantly, the "lazy" option (the scenario where you make no conscious decision, which I propose the majority of people follow in most cases) currently is to not use security. From a 2020 viewpoint, this simply is backwards, and we need to change it as soon as we can.

Changing to NTPv5 provides just that opportunity. We can simply standardize that security (with NTS) be enabled. You talked about the potential rollout of NTS, and this would give us the chance to really, really boost (predicted) numbers from <<50% to >>50% of users/machines/messages being secured. I believe we should do this, as anything else would just be a massive waste of opportunity.

TL;DR: I'm in favor of security being enabled by default in NTPv5 and using NTS to realize that. It presents an opportunity to massively increase the use of security in NTP traffic. If we believe that the cost is too great for some use cases, let us focus our energy on reducing it, instead of letting the opportunity go to waste!

Best regards,

Kristof

An: "Rich Salz" <rsalz=[email-masked]>, <[email-masked]>, <[email-masked]>
Von: "Ulrich Windl"
Gesendet von: "ntp"
Datum: 10.12.2020 08:23
Kopie: "[email-masked]" <[email-masked]>, "Dieter Sibold" <[email-masked]>
Betreff: [Ntp] Antw: [EXT] Re: NTPv5 draft

um 15:56
in Nachricht <[email-masked]>:
>     > unknown solution. Where were you when NTS was designed? And why does
>     > it need to be solved in NTPv5?
>

Regards,
Ulrich

---

From: Hal Murray <[email-masked]>
Date: Thu, 10 Dec 2020 03:06:59 -0800

[email-masked] said:
> I do not agree with the train of thought that because some users don't
> strictly need security for their use case, security should be disabled by
> default.

I don't think "default" makes sense when describing the protocol.  If the 
server supports it, the client can choose to use it or not.

"Default" would make sense if you are discussing a client option and/or the 
default configuration that is shipped by distros.

There is an ongoing discussion as to whether the protocol should require 
authentication with strong opinions on both sides.  I wouldn't use "default" 
there either.

---

From: James <[email-masked]>
Date: Thu, 10 Dec 2020 13:55:53 +0100

> would you suggest to fix it?

I have very deliberately avoided solutionising or mentioning NTS thus 
far to focus on the requirements and use-cases. NTPv5 + NTS may be 
appropriate and mitigate downgrade, but what is absent thus far is a 
document describing the protocol which contains normative language about 
the matter.

> downgrade or misconfiguration?
Kristof has written a really good description[1] of the issue around 
this which covers this point and a few others.
> Are you considering a bug where the
Having authentication enforced in the next version of the protocol does 
not prevent implementations from supporting older versions.
> If it is not an extension, how do you replace it when it's found to be
When it comes to the agility of authentication algorithms, having a 
baseline which implementations should support in addition to an IANA 
registry to allow for new algorithms should be sufficient. When it comes 
to insecurity with the protocol as it functions, this can be mitigated 
ahead of standardisation with thorough review, the use of existing known 
primitives (avoiding "exotic" crypto), formal verification etc.
> interleaved mode it doesn't matter how long it is, it's compensated.
To clarify I am not saying that is too long, I am saying that it should 
not be an issue for the use cases I have already described.
> Don't forget about pool.ntp.org. Do you not want NTPv5 to be supported

I very specifically called out the NTP Pool in my requirements document. 
Could you (or someone else reading) elaborate what specific concerns 
would be around the requirements I have described and their potential 
impact to deployment onto the NTP Pool?

- J

1: https://mailarchive.ietf.org/arch/msg/ntp/9Cz20MvJJaBBJozrhh_Qsvemi4E/

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 14 Dec 2020 13:31:27 +0100

On Thu, Dec 10, 2020 at 11:38:41AM +0100, [email-masked] wrote:
>    It seems to me that the answer is clearly that NTPv5 should natively make
>    available security that is strong (enough), as well as easy to deploy and
>    use.

I asked if the specification should recommend use of authentication,
but Dieter said it's not good enough. I don't think it should require
the use of authentication, but even if it did, it wouldn't change
security of the protocol itself.

I think it's really up to the implementations and their default
configurations. There is not much we can do about it in a protocol
specification.

>    1) First of all, this only makes abstract sense to me as a conclusion if
>    security enabled by default comes at significant cost - and I think we can
>    prevent this from being true, specifically by investing work into support
>    of a "two-step" message format, where all security (and, honestly, most
>    information overall) is only included in the "follow-up" message; then
>    security being enabled really has zero extra cost (apart from everything
>    being more accurate overall).

NTP is used everywhere. Some hardware doesn't have enough
memory/storage to support TLS/NTS. Some computers don't have an RTC or
cannot be assumed to start with correct time to be able to validate
certificates. Symmetric keys may not be practical. 

There are other costs, like the complexity of implementation and
its attack surface. NTS is much more complex than NTP. It's more
likely to have security issues, either in the protocol (TLS) or the
implementation. The threat model with simple unauthenticated NTP is
well understood.

>    2) Second of all, I think these use cases (where users don't need security
>    because they are using NTP in a closed controlled network) are the
>    exception rather than the norm. The majority of NTP traffic is going to
>    happen over the open internet, and security should pretty much
>    unconditionally be used in that scenario.

I agree secure NTP should be the norm, but the protocol shouldn't try
to enforce it.

>    As kind of an aside @Miroslav: I don't think anyone is claiming that
>    NTPv4+NTS has a security issue in the sense that it does not provide
>    adequate security when used (otherwise I really would like to explicitly
>    hear such concerns!).

Rich seems to be saying that if NTPv5 was redesigned for security, it
would be different from NTPv4 or the proposed NTPv5. I don't see how.

NTS in NTP is basically just an AEAD that authenticates and sometimes
encrypts the NTP data. It doesn't matter what it actually is
protecting, right? As long as the protocol allows all data to be
protected, there is no issue with security, e.g. downgrade attacks.
With NTS all security negotiation happens separately over TLS. NTP is
just a payload.

>    Changing to NTPv5 provides just that opportunity. We can simply
>    standardize that security (with NTS) be enabled.

What exactly do you suggest for the document to say?

>    TL;DR: I'm in favor of security being enabled by default in NTPv5 and
>    using NTS to realize that. It presents an opportunity to massively
>    increase the use of security in NTP traffic. If we believe that the cost
>    is too great for some use cases, let us focus our energy on reducing it,
>    instead of letting the opportunity go to waste!

I doubt NTPv5 can change the adoption of NTS. I'd say currently the
biggest issues are the dependency on time for certificate validation
and lack of support in pool.ntp.org. There is nothing NTPv5 can do
about that.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 14 Dec 2020 14:02:19 +0100

On Thu, Dec 10, 2020 at 01:55:53PM +0100, James wrote:
> I have very deliberately avoided solutionising or mentioning NTS thus far to
> focus on the requirements and use-cases. NTPv5 + NTS may be appropriate and
> mitigate downgrade, but what is absent thus far is a document describing the
> protocol which contains normative language about the matter.

Ok. Thanks for clearing that up.

> Having authentication enforced in the next version of the protocol does not
> prevent implementations from supporting older versions.

Or, supporting the next version without authentication.

If some implementation wanted to prevent its users from using
unauthenticated NTP, it could support only authenticated NTP and it
could do that with NTPv3, NTPv4 and any future version. The protocol
version doesn't really matter here.

> When it comes to the agility of authentication algorithms, having a baseline
> which implementations should support in addition to an IANA registry to
> allow for new algorithms should be sufficient. When it comes to insecurity
> with the protocol as it functions, this can be mitigated ahead of
> standardisation with thorough review, the use of existing known primitives
> (avoiding "exotic" crypto), formal verification etc.

To me it would make sense to have this separate from the NTPv5 on-wire
specification. NTP just needs its data protected. It's up to NTS or a
more general "secure NTP" document to specify how. Currently, NTS
requires TLS1.3 or later. When a major issue is found in TLS1.3 and
that requirement needs to be updated, it's not an issue specific to
NTPv5.

> To clarify I am not saying that is too long, I am saying that it should not
> be an issue for the use cases I have already described.

Ok.

I think there might be a requirement for the transmit timestamp to be
located close to the end of the protected data to allow an advanced
implementation to interrupt the authentication process, save a fresh
timestamp, and resume the process, in order to minimize the error in
the transmit timestamp. However, this might conflict with a
requirement to have the timestamp at a fixed offset to simplify a
hardware timestamping implementation.

> Could you (or someone else reading) elaborate what specific concerns would
> be around the requirements I have described and their potential impact to
> deployment onto the NTP Pool?

The issue with the pool is that there is no single trusted entity, but
a large number of volunteers, so NTS or another "secured NTP" would
have a different meaning from what would be normally expected. It
might be possible to prevent MITM attacks, but it's not possible to
prevent an attacker from joining the pool with their own server.

-- 
Miroslav Lichvar

---

From: Christer Weinigel <[email-masked]>
Date: Thu, 17 Dec 2020 15:13:24 +0100

> certificates. Symmetric keys may not be practical. 

Maybe such small devices shouldn't use NTP.  From what I understand
roughtime might be a better choice.  It only uses a few hardcoded
cryptographic primitives so the size of implementation ought to be
fairly small.  Since a roughtime client is expected to have a hardcoded
list of servers and associated public keys it does not have the chicken
and egg problem of needing accurate time to be able to validate the
certificates to be able to verify a NTSKE server to get time.

Of course, public key distribution is a bit of an issue with roughtime,
but if the big players such as RedHat/Fedora, Debian/Ubuntu and
Yocto/OpenEmbedded/Buildroot curates a list with a couple of hundred
roughtime servers, at least some of those servers ought to survive over
the lifetime of a device.  If a client chooses a half a dozen random of
servers to query from the list and all of them agree on time to within a
second, that should give the client fairly good confidence that the time
is received is correct.

  /Christer