Subject: [Ntp] NTS for NTP draft

From: Danny Mayer <[email-masked]>
Date: Fri, 3 Nov 2017 14:00:03 -0400

First I'd like to apologize for not review this draft before but the
last year has been extraordinarily full for me and I haven't had time to
pay attention.

I read the draft just before the interim meeting and it's not ready for
last call. I'm going to just deal with the major issues as I see them.

1. Fundamentally ALL NTP packets are client/server, even the control
ones. However section 1.2 seems to think that symmetric peer and control
mode are exchanging packets. That's actually a total misunderstanding of
the protocol. Symmetric peer mode are only different in how the
timestamps are analyzed and when they return a response packet.
Symmetric peers never exchange packets in the way that the document
seems to think. A peer will send a request and get a response. At a
separate time the server that responded to the packet will send a
request to the other peer and get a response.

2. Peer, Client/Server are all handled the same way in the protocol.
They only differ in the way they respond and how the data is handled
when analyzing the data in the packets.

3. Broadcast and Multicast are only different in that the server sends a
UDP broadcast or multicast NTP packet and a client which has subscribed
to the broadcast or multicast group picks it up. The client does not
initiate these packets.

3. Control packets are initiated by a client and responded to by the
server. These are the only packets that one might want to secure to
prevent DDOS attacks or even encrypt. However unlike other packets they
can be handle by a key exchange OOB and there is no requirement to look
at the protocol timestamps. Only admins really needs these packets and
they should be controlling both ends.

4. The three DTLS proposals as documented in section 1.2 are useful
ideas as a discussion paper but doesn't mean that they should all be used.

5. DTLS-encapsulated NTPv4 is not practical as it assumes that you are
in effect keeping a channel going. In fact NTP packet requests can vary
between every 16 seconds to once a day so this is not a good idea. Even
worse, the timestamps will be way off what they need to be and would
result in a large jitter among other problems which will result in them
being rejected as too unreliable by the selection algorithms. Control
mode doesn't need it since it can be secured using other methods as only
an admin of such a server might need to use control mode. Symmetric peer
mode as I stated above is the same as client/server and needs to be
handle in the same way.

6. NTP packets are already protected against replay attacks so DTLS does
not provide any additional protection.

7. There is no benefit to encrypting Extension Fields. There's nothing
secret about them.  NTS should be about the whole packet and not about
the individual fields.

8. The response packet can be smaller than the request packet. For that
matter if the response is slightly larger then it does not qualify as an
amplification in the security sense. I have actual use cases which would
make the response smaller.

9. Section 1.1 seems to be nothing but a wish list of attributes about a
packet but unless each one is spelled out in detail in the specification
and why it's useful there's no point to it.

10. AEAD (section 5.1.5) is not clear at all. When is it supposed to be
used, why it should be used, what are the benefits and what are the
issues with using it?

11. New Cookie (Section 5.1.6) why it is needed and the benefits of it.
Furthermore in the discussion of NTS cookies (section 7) is this
sentence: "Clients MUST NOT examine the cookie under the assumption that
it is constructed according to this section". Clients should be free to
examine anything they want, including a cookie. What is preventing them
from examining the cookie?

12. In Section 7 we see: "Servers should periodically generate a new
pair (I,K)". Doesn't that mean that it needs to maintain state which we
already agreed is not a good idea for a server? Or does that mean that
the server only has one cookie for all clients? Further on it talks
about accepting old ones which means keeping more state. This does not
scale.

13. TLS 1.3 is almost ready to be published as an RFC so why not use
that as a minimum started point?

Danny

---

From: Hal Murray <[email-masked]>
Date: Fri, 03 Nov 2017 15:27:04 -0700

How much would it simplify things to drop everything but the mainline 
client/server modes?

How much would that help security?

-- 
These are my opinions.  I hate spam.

---

From: [email-masked]
Date: Sun, 5 Nov 2017 19:47:14 +0100

The version 10 of the draft (uploaded at 30th Oct) contains only the client-server mode. Everything else is removed.

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

>To: [email-masked]
>From: Hal Murray 
>Sent by: "ntp" 
>Date: 11/03/2017 23:27
>Cc: [email-masked]
>Subject: Re: [Ntp] NTS for NTP draft
>
>_______________________________________________
>ntp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ntp
>

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 6 Nov 2017 13:29:50 +0100

> request to the other peer and get a response.

That doesn't sound right to me. How would the peers know which packet
is a response and which is a request? There is no bit in the NTP
header that would indicate that. The active/passive mode is related to
how is the association created, it does not say if it's a request or
response, except the case when a server does not mobilize an
association with a host that's sending active mode packets and
responds with passive mode packets similarly to a server in the
client/server mode.

Generally, peers send packets in their own interval and each packet is
a request and response at the same time. The peers don't even have to
use the same interval. One peer can be sending packets at a faster
rate then the other and the protocol should still work.

The client/server mode can be described as a special case of the
symmetric mode, but they are not the same.

> not provide any additional protection.

Not in the symmetric mode. The problem is that the packets are
requests and responses at the same time. Replaying an older packet can
disrupt the NTP state of the peer (as it cannot remember all packets
that have been sent) and cause a denial of service.

The issue was described in http://eprint.iacr.org/2016/1006. Please
see the appendix B.

The peers could require that each received packet has a newer
timestamp, but that would not allow backward steps and it would still
not prevent attacks in cases like when a peer has no RTC and starts in
1970, but the other peer thinks it's a timestamp from 2106 (in the
next NTP era).

As I understand it, wrapping NTP packets in DTLS would fix this issue.
However, the use of a different transport for NTP timing messages
would create few other issues and that's why it was removed from the
latest version of the draft.

> make the response smaller.

Can you provide some examples? NTP packets generally need to have a
symmetric length in order to not create an asymmetric delay, so if
there are such cases, padding the response or request should be
recommended to not break the symmetry.

-- 
Miroslav Lichvar