Subject: [Ntp] NTS quirks

From: Hal Murray <[email-masked]>
Date: Sat, 23 Mar 2019 17:59:31 -0700

Both NTS-KE and NTP extensions have a type-length header for chunks of data.  
Unfortunately, the lengths in NTP extensions include the header while the 
lengths in NTS-KE only cover the payload.

Eric calls this sort of things a bug attractor.  It's too easy to cut-paste 
some code or call the wrong subroutine.  I got it wrong.  Thanks to Martin 
Langer for pointing out my error.  That would have been really nasty to debug 
without help.  My code worked fine talking to itself.

Existing RFCs describe NTP extensions.  I think we should change NTS-KE to 
match NTP extensions.  If not, at least add some BIG warnings to the spec.  
Maybe copy the padding rules too.

-----

Draft 17 says ALPN is REQUIRED.  That's not supported by older versions of 
OpenSSL that are still in use by a few old but still supported distros.  I 
think it was added  in 1.0.2

CentOS-6 is using 
  OpenSSL 1.0.1e-fips 11 Feb 2013

NetBSD 7.2 is using:
  OpenSSL 1.0.1u  22 Sep 2016

-----

There is a bug in OpenSSL 1.1.1a that doesn't support "long" strings when 
exporting keying material.
  // Subject: [Ntp] [NTS4NTP] info for NTS developers
  // From: Martin Langer <[email-masked]>
  // Date: Tue, 15 Jan 2019 11:40:13 +0100
  // https://mailarchive.ietf.org/arch/msg/ntp/nkc-9n6XOPt5Glgi_ueLvuD9EfY

The spec calls for "EXPORTER-network-time-security/1".  That's too long.  We 
have been testing with "EXPORTER-nts/1".  OpenSSL 1.1.1b is out.  It fixes 
that bug, but some systems are still using 1.1.1a.

I think we should switch to a shorter string so we don't have to be concerned 
with 1.1.1a.

In an off-list discussion, Christer Weinigel suggested "EXPORTER-ntske/1".  (I 
think that is short enough.)  The idea is to take advantage of the registry 
for ALPN strings since there is no registry for exporter strings.

-----

Cookies are ballpark of 100 bytes.  I think the official MTU is still 576 
bytes.  So NTP packets with 5 or 6 Cookie Placeholders will be over the limit. 
 I think the practical limit is closer to 1500 bytes on most of the internet.

It's probably worth adding a note to the spec.  Maybe we should limit the 
number of Cookie Placeholders.

-----

Is anybody working on a Wireshark plugin?  (or however that works)

-----

It may be appropriate to write a companion document to collect information 
that isn't appropriate for an RFC.  Little things would be a heads-up on MTU 
and NTP packet filtering.

Big things would be the ratcheting on cookie keys as one way to keep NTS-KE 
servers in sync with NTP servers when they aren't co-located on the same 
system/process.

-- 
These are my opinions.  I hate spam.

---

From: Daniel Franke <[email-masked]>
Date: Sun, 24 Mar 2019 03:55:56 +0100

> Maybe copy the padding rules too.

I can add a note about the difference, but I'm absolutely not changing
the NTS-KE rules. The length rules for NTP extensinos are bizarre and
are themselves a defect attractor. In particular if a parser forgets
to check that length >= 4 then you can throw it into an infinite loop
by passing length=0. Having a length that describes anything other
than the number of bytes that immediately follow is also a pain when
using certain parser combinator libraries. And NTP's padding rules
have caused all manner of headaches for extension designers.

>   OpenSSL 1.0.1u  22 Sep 2016

1.0.1 is already out of security support and 1.0.2 will be at the end
of this year. People using distros this ancient are doing so because
they have a working configuration they don't want to touch; they
aren't going to be bringing new functionality like NTS onto them.

> for ALPN strings since there is no registry for exporter strings.

The registry for exporter strings is at
https://www.iana.org/assignments/tls-parameters/tls-parameters.xml#exporter-labels
and the longer form matches the style of other entries there. I don't
want to break convention for the sake of a bug that existed in one
implementation for a couple of months.

> number of Cookie Placeholders.

The MMTU for IPv6 is 1280 bytes and that's what we should consider the
practical limit. Ethernet MTU is 1500 but you shuold assume that VPN
tunnels and the like might be swallowing the difference. I can add a
sentence making a note of the issue but I don't want to make any
prescriptive change; while fragmenting time packets is a bad idea,
there's no reason to actually prohibit doing so. And using
AEAD_AES_SIV_CMAC_256 and the recommended maximum of eight cookies,
packets already fit inside a 1280-byte MTU.

> Is anybody working on a Wireshark plugin?  (or however that works)

Not that I know of. It would be a good idea.

> servers in sync with NTP servers when they aren't co-located on the same

We don't need a separate document for implementation notes; just a few
sentences inline should suffice. The ratchet details will eventually
be a separate, standards-track RFC which covers other issues related
to pool-management as well. But I don't want to start that yet until
we have some real-world experience from pool operators.

---

From: Harlan Stenn <[email-masked]>
Date: Sat, 23 Mar 2019 20:01:06 -0700

> have caused all manner of headaches for extension designers.

Please say more about your last sentence.

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!

---

From: Daniel Franke <[email-masked]>
Date: Sun, 24 Mar 2019 04:13:38 +0100

> Please say more about your last sentence.

In most protocols that have padding requirements, the length field
reflects the actual length of the content, and the receiving party
computes how much padding follows by rounding up to the next multiple.
In NTP, the length field includes the length of the padding. For
variable-length content whose length isn't guaranteed to already be a
multiple of four, this creates a need for an inner length field or
some or some other added complexity to disambiguate where the content
ends and the padding begins.

---

From: Hal Murray <[email-masked]>
Date: Sat, 23 Mar 2019 22:05:45 -0700

> I can add a note about the difference, but I'm absolutely not changing the
> NTS-KE rules. The length rules for NTP extensinos are bizarre and are
> themselves a defect attractor. In particular if a parser forgets to check
> that length >= 4 then you can throw it into an infinite loop by passing
> length=0. Having a length that describes anything other than the number of
> bytes that immediately follow is also a pain when using certain parser
> combinator libraries. And NTP's padding rules have caused all manner of
> headaches for extension designers. 

> In most protocols that have padding requirements, the length field reflects
> the actual length of the content, and the receiving party computes how much
> padding follows by rounding up to the next multiple. In NTP, the length field
> includes the length of the padding. For variable-length content whose length
> isn't guaranteed to already be a multiple of four, this creates a need for an
> inner length field or some or some other added complexity to disambiguate
> where the content ends and the padding begins.

Any possibility of fixing the NTP extension length rules?

How about a type that is a wrapper for a mode where new length rules apply?  
Costs 4 bytes.

Shift to a new port number where new rules apply?

How much overlap is there between systems using old extension length rules and 
systems that will use NTS?

With modern processors/memory/caches, does alignment have a significant impact 
on performance?  I'm interested in the lower end as well as high end.

---

From: "Dieter Sibold" <[email-masked]>
Date: Sun, 24 Mar 2019 09:19:29 +0100

See my comments below.

Dieter Sibold
[email-masked]

> have caused all manner of headaches for extension designers.
I agree with Daniel. A note in the document should be sufficient to make 
implementors aware of this pitfall.

>>   // 
>> https://mailarchive.ietf.org/arch/msg/ntp/nkc-9n6XOPt5Glgi_ueLvuD9EfY
>>
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Harlan Stenn <[email-masked]>
Date: Sun, 24 Mar 2019 01:55:10 -0700

> implementors aware of this pitfall.

You're talking about the EF length in the header?

Are you talking about the padding rules added by 7822?

H
--

---

From: Daniel Franke <[email-masked]>
Date: Sun, 24 Mar 2019 10:12:00 +0100

> You're talking about the EF length in the header?

Yes.

> Are you talking about the padding rules added by 7822?

No, I'm talking about the semantics of the length field. RFC 7822
added new rules about how long an EF can be, but the semantic that
length field reflects the padded rather than unpadded length has been
there all along.

---

From: Christer Weinigel <[email-masked]>
Date: Sun, 24 Mar 2019 10:52:52 +0100

> Any possibility of fixing the NTP extension length rules?

I'd say no, unless we start using a new port and drop all NTP compatibility.

> How about a type that is a wrapper for a mode where new length rules apply?

Probably not worth it, extension fields that need an exact length can 
add their own length field, like the authenticator record with nonce 
length and ciphertext length.

> Shift to a new port number where new rules apply?

Yes, that would be a possibility, but I'd rather not start over and have 
to redo NTS from the beginning again. :)

> on performance?  I'm interested in the lower end as well as high end.

Definitely.

The ARM Cortex M micro controllers support unaligned accesses in 
hardware, but they are much slower than aligned accesses.  (On an Cortex 
M0 without cache, an unaligned read will be split into two aligned reads 
on the bus which will take twice as long to complete).  Some operating 
systems configure the MCU to trap on unaligned accesses which makes them 
even slower.

On modern X86-64 systems it's also an issue, the architecture supports 
unaligned accesses but they do have a performance impact, even though 
caches mitigate it.  Most SIMD instructions (SSE and AVX) do not support 
unaligned accesses and will raise a genereral protection exception if 
data is not aligned on a 32-byte boundary (which means that 32 bits 
isn't enough, so one has to be careful about this anyway).

For a FPGA implementation of NTS having to be able to read octet aligned 
data will roughly require four times as much logic as being able to read 
32 bit aligned words.

   /Christer

---

From: "Dieter Sibold" <[email-masked]>
Date: Mon, 25 Mar 2019 19:48:46 +0100

Hi Daniel, Marcus and Ragnar,
to address this issue I suggest to add the following language to the end 
of Sec. 5.6.

Note, that in contrast to the NTS-KE records the length field of an 
extension field indicates the length of the entire extension field in 
octets, including the fields: Field Type, Length, Value, and Padding 
[RFC7822].

I’ve already added that to the git repro. Please elaborate!

- Dieter

Dieter Sibold
[email-masked]