Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 1 Sep 2017 09:57:57 +0200

On Thu, Aug 31, 2017 at 10:36:34PM +0200, [email-masked] wrote:
> During the NTP interim meeting in Boston, Oct 2016 we had a thorough discussion of how to transport NTP's symmetric mode. At this time we had consensus to postpone the encapsulation of DTLS records within EF. Therefore, the draft represents the decisions take at that time. As Daniel pointed out. The current scheme to protect the symmetric mode has no disadvantage regarding time synchronization performance. I would guess that for the majority of mode 1/2 configuration it will work just well. It will certainly not work for the special configuration you mentioned. But an alternative approach can be specified, if future reveals that for any reason this is mandatory for the symmetric mode. But until that we should promote the current approach.

If DTLS over NTP was just postponed, why specify now a different
transport for this rarely used mode? Is anyone actually interested in
implementing the symmetric mode over DTLS as it is proposed? If I
understand it correctly, there is no plan to support it in any of the
(few) existing open source implementations. Isn't there a rule about
not specifying things for which there is no demand?

Maybe I'm completely wrong, but to me it feels like there is a
pressure for NTS to cover as many modes of NTP as quickly as possible.
If we support two different transports, with every new change in NTP
we will have to ask if and how it works in each of them.

-- 
Miroslav Lichvar

_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 1 Sep 2017 09:57:57 +0200

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 1 Sep 2017 10:11:22 +0200

On Thu, Aug 31, 2017 at 08:27:46PM -0400, Daniel Franke wrote:
> Miroslav, I just pushed a bunch of new detail in section 4 to git. Let
> me know what you think of it and whether it affects your vote.

I think it does clear up the issue with two active peers. Thanks. It
doesn't change my vote, however.

The following sentence might need to be expanded a bit further to
prevent lasting DoS attacks on B.

	  If, likely as a result of a configuration error, party A is
	  configured as a symmetric active peer of party B, but party B
	  is neither accepting DTLS handshakes from party A nor
	  initiating one with it, then after a suitable number of failed
	  attempts, party A MAY fall back to acting as an NTP client
	  (mode 3) of party B using NTS-KE and NTS Extension Fields for
	  NTPv4.

If a MITM attacker prevents A from making a DTLS connection with B and
it falls back to the client/server mode using NTS-KE, which is not
blocked by the attacker, it should still be trying to make the DTLS
connection. Maybe a better way to say this would be that party A MAY
create a parallel client/server association with B using the NTS-KE.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 1 Sep 2017 10:11:22 +0200

-- 
Miroslav Lichvar

---

From: [email-masked]
Date: Fri, 1 Sep 2017 11:03:12 +0200

For the given application (comparison of performance of two different 
techniques), I fail to see how that is supposed to work.
Should running code be created for BOTH transport mechanisms (DTLS 
encapsulation and regular NTP packet with authenticator token) before a 
decision is made?
I believe that is taking the "running code" maxim too far.

Von:    "Gary E. Miller" <[email-masked]>
An: 
Kopie:  "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Datum:  01.09.2017 00:18
Betreff:        Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp
Gesendet von:   "ntp" <[email-masked]>

Yo Daniel!

On Thu, 31 Aug 2017 08:34:02 -0400
Daniel Franke <[email-masked]> wrote:

> Lots of people on this list seem to have the intuition that sending
> time packets over DTLS can never be as accurate as sending them over
> the NTP port with an authenticator attached. But as I showed in my
> analysis the other day, that just ain't so.

Analysis is great, but I'd like to see running code.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
                 [email-masked]  Tel:+1 541 382 8588

                     Veritas liberabit vos. -- Quid est veritas?
    "If you can?t measure it, you can?t improve it." - Lord Kelvin
[Anhang "attpwg8d.dat" gelöscht von Kristof Teichel/PTB] 
_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: [email-masked]
Date: Fri, 1 Sep 2017 11:03:12 +0200

Yo Daniel!

RGDS
GARY

---

From: Kyle Rose <[email-masked]>
Date: Fri, 1 Sep 2017 10:29:06 -0400

I am strongly in favor of moving this draft toward standardization.
This is tremendous work that will eliminate entire classes of attacks
against protocols that depend on synchronized time.

A few comments:

(1) I couldn't figure out if it is possible for the client to request
multiple cookies with time synchronization requests. If it isn't, it
seems like it should be to avoid the inevitable re-establishment of
keys if the client's cookie pool permanently drops by one every time a
packet is lost. Being able to request more than one cookie will enable
the client to maintain the recommended pool of 8.

(2) In section 5, the description of the record type field seems
wrong. It says q( A 15-bit integer in network byte order (from
most-to-least significant, its bits are record bits 7-1 and then
15-8). ). This seems to imply that (for example) the value 16385 would
be encoded as 000000100000001 when read from left-to-right in the
given diagram, when I believe it should be encoded as 100000000000001.
I would just lose everything between the parentheses: it seems
sufficient to say that record type is a 15-bit unsigned integer in
NBO.

(3) Section 5.2 states that key material "SHALL" be extracted
according to RFC 5705. What is the plan if some TLS 1.3-specific
mechanism deprecates 5705?

Kyle

On Wed, Aug 9, 2017 at 12:41 AM, Karen O'Donoghue <[email-masked]> wrote:
> Folks,
>
> This begins a three week working group last call (WGLC) for "Network Time Security for the Network Time Protocol”.
>
> https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/
>
> Please review and provide comments to the mailing list by no later than 31 August 2017. Earlier comments and discussion would be appreciated. Please note that the chairs will be using this WGLC to determine consensus to move this document forward to the IESG.
>
> Also, as a reminder, we have migrated the working group mailing list to IETF infrastructure. Please respond to [email-masked]. ]
>
> Regards,
> Karen and Dieter

---

From: Kyle Rose <[email-masked]>
Date: Fri, 1 Sep 2017 10:29:06 -0400

A few comments:

Kyle

---

From: Kyle Rose <[email-masked]>
Date: Fri, 1 Sep 2017 10:32:36 -0400

> be encoded as 000000100000001 when read from left-to-right in the

Er, I mean 000000110000000. Either way, still seems wrong.

Kyle

---

From: Kyle Rose <[email-masked]>
Date: Fri, 1 Sep 2017 10:32:36 -0400

Kyle

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 1 Sep 2017 14:46:57 +0000

➢     I think it does clear up the issue with two active peers. Thanks. It
    doesn't change my vote, however.
    
I suggest we try to avoid using the word “vote” here.  We work by rough consensus, we don’t count votes.  It is up to the chairs to determine consensus if it’s not “obvious” (for some definition of the word). 

It might seem like a minor thing, but I don’t think it is.  “I vote against” is different from “I’m opposed,” both from a mindset and procedural viewpoint.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 1 Sep 2017 14:46:57 +0000

---

From: Daniel Franke <[email-masked]>
Date: Fri, 1 Sep 2017 11:25:51 -0400

> the client to maintain the recommended pool of 8.

That's exactly what the NTS Cookie Placeholder extension is for.

          The client MAY include one or more NTS Cookie Placeholder
          extension field, which MUST be authenticated and MAY be
          encrypted. The number of NTS Cookie Placeholder extension
          fields that the client includes SHOULD be such that if the
          client includes N placeholders and the server sends back N+1
          cookies, the number of unused cookies stored by the client
          will come to eight. When both the client and server adhere
          to all cookie-management guidance provided in this memo, the
          number of placeholder extension fields will equal the number
          of dropped packets since the last successful volley.

> sufficient to say that record type is a 15-bit unsigned integer in

Already fixed in git.

> mechanism deprecates 5705?

Current TLS 1.3 drafts swaps the KDF implementation from TLS-PRF for
HKDF but keep the interface exactly the same. The intent, which seems
clear at least to me, is that anything which currently uses RFC 5705
will use TLS 1.3's exporter to extract keys from TLS 1.3 sessions.
Once TLS 1.3 is finalized, we can publish an update to clarify this if
it isn't clear enough already.

If even the *interface* changed then we'd have to do an update for
sure, but I think the odds of that approach nil.

---

From: Daniel Franke <[email-masked]>
Date: Fri, 1 Sep 2017 11:25:51 -0400

Already fixed in git.

---

From: Kyle Rose <[email-masked]>
Date: Fri, 1 Sep 2017 13:31:14 -0400

> it isn't clear enough already.

I think it's worth clarifying this because you don't want one
implementation using 5705 and another using HKDF and agreeing on
different keys. For some use cases it doesn't matter (server deriving
keys that only it knows), but in cases of shared keys we would have a
problem.

Kyle

---

From: Kyle Rose <[email-masked]>
Date: Fri, 1 Sep 2017 13:31:14 -0400

Kyle

---

From: Daniel Franke <[email-masked]>
Date: Fri, 1 Sep 2017 15:01:12 -0400

> keys that only it knows), but in cases of shared keys we would have a

Got any idea for how to phrase this without creating a normative
reference that blocks us on TLS 1.3 publication?

---

From: Daniel Franke <[email-masked]>
Date: Fri, 1 Sep 2017 15:01:12 -0400

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 1 Sep 2017 19:03:41 +0000

Just say something like
	Implementations MUST use HKDF
I know the temptation is to want to give a rationale but you needn’t put that in the text.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 1 Sep 2017 19:03:41 +0000

Just say something like

---

From: Daniel Franke <[email-masked]>
Date: Fri, 1 Sep 2017 15:14:46 -0400

> reference that blocks us on TLS 1.3 publication?

So actually, I just took another close look at 5705 and at the history
of the TLS RFCs, and I think the Right Thing is already unambiguous.
RFC 5705 says to apply "TLS Pseudorandom Function in use for the
session". The TLS PRF has already changed incompatibly in past TLS
versions. In TLS 1.2, it's part of the ciphersuite's specification. In
1.1 and prior, it was fixed, and based on an XOR of MD5 and SHA1. So
any correct RFC 5705 implementation is already taking protocol version
into account and choosing what function to apply accordingly.

---

From: Daniel Franke <[email-masked]>
Date: Fri, 1 Sep 2017 15:14:46 -0400

---

From: Kyle Rose <[email-masked]>
Date: Fri, 1 Sep 2017 15:24:51 -0400

On Sep 1, 2017 3:14 PM, "Daniel Franke" <[email-masked]> wrote:

Ok, I'm satisfied. I just checked the relevant text in the TLS 1.3 draft,
and it looks like it would be unambiguous here:

q( [RFC5705] defines keying material exporters for TLS in terms of the TLS
pseudorandom function (PRF). This document replaces the PRF with HKDF, thus
requiring a new construction. The exporter interface remains the same. )

Kyle

---

From: Kyle Rose <[email-masked]>
Date: Fri, 1 Sep 2017 15:24:51 -0400

Kyle

---

From: Paul Gear <[email-masked]>
Date: Sat, 2 Sep 2017 13:40:10 +1000

On 29/08/17 23:16, [email-masked] wrote:
> "Ulrich Windl" <[email-masked]> schrieb am
> 29.08.2017 10:32:03:
> > Von: "Ulrich Windl" <[email-masked]>
> > An: <[email-masked]>
> > Datum: 29.08.2017 10:40
> > Betreff: Antw: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp
> > (Objectives Subsection)
> >
> > Hi!
> >
> > I'm not deep in it, but the basic discussion seems to be that Dave
> > Mills thinks some things are "good enough", while others think they
> > are not. Maybe point out more clearly where any why things are not
> > good enough.
> > I must agree that I, too, see little practical difference between  a
> > sub-nanosecond timestamp and a random number (just to name one
> > example), considering that the network delay is above microseconds.
> > So the chances for a successful replay should be less than 1/1000th,
> right?
>
> I guess this specific example is a matter of perspective: consciously
> settling for ~1/(2^10) does not sound optimal to me when the
> alternative is to go for ~1/(2^128), at the cost of a few additional
> octets.
> Also, I appreciate Daniel's point that it is simply good practice to
> make the securtiy properties of a protection mechanism independent
> from the content of the protected protocol.
>
> Additionally: do we have any argument that introducing a nonce (as per
> good general practice) would actively be a significant detriment?

Hi everyone,

One of the things I've not been able to explain for myself in NTS draft
9 is why we need the Unique Identifier extension field.  My logic is as
follows:

a) For clients which require unlinkability, NTS requires the use of
Client Data Minimization.  Such clients generate a 64-bit value
"uniformly at random" for the Transmit Timestamp.  This timestamp is
authenticated by the NTS Authenticator and so any replay attack would
need to replay the packet in its entirety (otherwise it would be ignored
by the client as failing authentication).  When a client following
Client Data Minimization generates a Transmit Timestamp value to put in
the packet, it must also save the real T1 locally in order to perform
the correct time calculation when the reply arrives.  So for a replay
attack to succeed, it would need to both successfully match the Transmit
Timestamp, and *correspond to an in-flight poll*.  For a packet replayed
after the original reply, this would not be the case.

b) For NTS clients which do not require unlinkability, all of the same
logic applies, except the Transmit Timestamp would have a much smaller
range of possible values.  However, all the same checks would need to be
performed by the client, so again a replay attack would not be possible.

c) For ordinary NTP clients which do not use NTS, all of the same logic
still applies, except that in the absence of strong authentication, a
MitM could forge a reply before the server's response was returned
(although this is not really a replay attack).  A reply after the
server's response would again not correspond to an in-flight poll, so
would be discarded.

So it seems that in all scenarios, the Unique Identifier adds no
benefit.  What am I missing?

If the answer is "nothing" and I've covered all the scenarios, then I'd
like to see the Unique Identifier dropped, since it adds 32 unnecessary
octets to the packet.

Thanks in advance,
Paul

---

From: Paul Gear <[email-masked]>
Date: Sat, 2 Sep 2017 13:40:10 +1000

Hi everyone,

Thanks in advance,
Paul

---

From: Harlan Stenn <[email-masked]>
Date: Sat, 16 Sep 2017 01:08:39 -0700

I'm reading the latest version from Daniel, dated 26 June but last
modified on 1 Sept (or so).

Some of the points I raised in my email of 27 August 2017 22:05:02 -0700
have been addressed.  Most have not.

I think I have (re)captured all of my points below.

While folks have asked for technical comments, it may be that clearing
up at least some of the more significant editorial comments will result
in a better proposal.

TL;DR: I oppose advancing the document as it currently stands as a
standards-track document, for the reasons below.

This document might be fine for EXPERIMENTAL status, which I think we
should do if we aren't planning to be certain that it works correctly
before advancing this document.  It might also be OK for this document
to be INFORMATIONAL.

Once we have confidence that this specification is robust, I'd be happy
to see it as a STANDARDS track document.

** Technical comments:

1.1. Objectives
- Identity:  Just a comment.  If we don't know what time it is, how can
we trust an X.509 PKI?  This is somewhat addressed by 9.2., and I'd
appreciate clarification and assurances from additional sources.

- Authentication: The authentication functionality of NTS is no
different from the existing symmetric key encryption already provided by
RFC5905, correct?

- Confidentiality: Is the only expected current use of this facility the
cookie supply sent from the server to the client?

- Replay prevention: Again, the core NTP specification already has
replay prevention.  The proposed language is misleading, implying that
without NTS there is no replay protection.  If the existing core
protection against replay is inadequate, please describe the problem(s).
 You could also say "NTS offers another, additional layer of replay
prevention beyond what NTP already provides."

- Request-response consistency: Again, the core NTP protocol already has
request-response consistency checks, where useful.  The proposed
language is misleading, implying that without NTS there is no
request-response consistency checking.  If the existing checks for
request-response consistency is inadequate, please describe the
problem(s).  You could also say "NTS offers another, additional layer of
request-response consistency checks beyond what NTP already provides."

- Unlinkability:  The new language is an improvement.  Even so, - the
stated threat seems extraordinarily unlikely to be possible if more than
several networks are involved.  Even if such a threat was possible and
used, if the client/server model for NTS is to use NTP packets with NTS
extension fields, an outside observer can still see that there is a
client sending requests to a set of servers that some other client has
used before.  How is that traffic not "linkable"? This "feature" seems
to be a red-herring.

- Non-amplification: Does this mean that the NTS proposal is attempting
to enforce non-amplification of NTP packets even if NTS is not being
used?  Is "never responding to a request with a packet larger than the
request packet" inviolate?  This sounds like micro-management to me, and
can easily be thwarted by bad guys who just send a bigger packet from a
forged source address to a server.  As I wrote before: The core problem
is DDoS.  Amplification is a secondary problem.  Sure, the avoidance of
amplification is a useful interim step.  But the target protocol isn't
the place to solve the DDoS problem.  DDoS is basically an "overcommit"
problem.  BCP38, anyone?

- Scalability: The way this is phrased is confusing.  If this goal is
specific to NTS, then it should say so.  Given the subsequent
discussions about C2S, S2C, etc., it also seems disingenuous.  Aside
from these things, it seems to be another red-herring.  More detail below.

- DTLS-encapsulated NTPv4: No mention is made of the fact that this
method will increase timing jitter, and degrade the quality of
timekeeping.  This is especially troublesome given that peer mode is
mostly used for groups of lower-stratum servers offering time to many
clients.  I believe this degradation MUST be disclosed.

1.2. Protocol Overview

- NTS EFs for NTPv4: Saying NTS EFs are suitable for client/server but
not for other modes seems incorrect to me.  If NTS-KE had the option to
exchange keys for both sides, then NTS EFs would be suitable for
symmetric mode, and I submit, offer better time quality than the
proposed symmetric mode over DTLS.

The premise that "all server state must be avoided" should be
re-examined.  We already need to maintain some server state to watch for
attacks, and no analysis has been provided to show what the tradeoffs
are between maintaining some server state compared with the
computational costs of regenerating key validation information from the
incoming client cookie.

~It is intended that DTLS will be used for symmetric and control modes,
and NTS-KE+NTS-EFs will handle client/server.~  See 2 paragraphs above,
for a request to understand why NTS-KE+NTS-EFs cannot be used for
symmetric mode.  Also, there are control mode situations where UDP is
suboptimal, and a more functional communication would be desired.

Last paragraph: "(This constant refreshing of cookies is necessary in
order to achieve NTS's unlinkability goal.)" - please describe this
better, as it still seems to me that there is plenty of information
available in the base packet, including the destination host and several
other fields, that would be useful for determining linkability.  See
"Unlinkability" comment above.

4. The DTLS-encapsulated NTPv4 protocol

I believe this section should discuss the degradation that will(?) occur
when transporting NTPv4 packets over a DTLS connection.  This includes:

- current inability to use interleave mode, because current DTLS
  implementations don't support SO_TIMESTAMPING, for the transmit
  timestamp
- potential for UDP packet fragmentation
- likely need to copy the NTP packet into DTLS packets
- any issues around grabbing the receive timestamp

There might be others - this is the list off the top of my head.

4.1 says "Implementations may find that they have multiple, redundant
DTLS sessions open with the same peer."  Shouldn't the protocol take
steps to prevent this from happening?  I need to read this document
again to understand this situation, as it seems to me that it should not
happen in general, and if it did happen, there should be specific,
listed cases, and then specific actions should be taken to "clean up."
I'm not sure about these things, but I am curious about them and wonder
if they should be better described.

6.2. Packet structure overview

- "Possibly, some additional extensions which are neither encrypted nor
authenticated.  >These are discarded by the receiver.<"  The part about
discarding EFs after the NTS packet IS wrong - it's over-reach.

- The purpose of the cookie extension field is to enable the server
  to offload storage of session state onto the client.

As above, this MAY be useful.  It may not always be useful, and an
analysis should be done to understand the time/space tradeoffs between
using a cookie and having to regenerate data based on the cookie, and
saving some state on the server.  This may not be significant, but we
should have a proper engineering basis for the decision.

- The purpose of the unique-identifier extension field is to protect
  the client from replay attacks.

The core protocol ALREADY has replay prevention protection.  Please show
how that protection is defective or inadequate.  Or make the editorial
change to say the purpose of the UIEF is to provide ADDITIONAL
protection from replay attacks.

"Possibly, some additional extension fields which are neither
 encrypted nor authenticated.  These are discarded by the receiver."

No.  Overreach.  The NTS proposal must not dictate policy outside of its
scope.  Lose "These are discarded bu the receiver."

We do not want to burn a separate EF type for each NTS EF "directive",
6.[3456].

6.3: "Historically, NTP's origin timestamp field has played
   both these roles, but for cryptographic purposes this is suboptimal
   because it is only 64 bits long and, depending on implementation
   details, most of those bits may be predictable."

Please substantiate this claim.  It smells of herring and/or FUD.

6.4: NTS Cookie EF:  If the NTS-KE is bi-directional, then NTS EFs could
also be used for symmetric mode associations.

6.5: NTS Cookie Placeholder: Ditto re 6.4 above.  Furthermore, I don't
believe that the claim about amplification is significant.  It is also
unclear that timekeeping accuracy is universally negatively affected if
the size of the client and server responses differ.  LAN and WAN?  Wired
and wireless?  Overloaded channels v. "not overloaded" channels?

6.6: NTS AEE EF: See 6.4 above.

Where is the MAC?

Is it encrypted?

NTP has traditionally allowed for several layers of protection and
checking.  If the base packet checks fail, we do no more processing of
the packet.  If the base packet checks succeed, then if the packet is
authenticated we are able to make sure the packet passes the
authentication MAC checks.  It is *only* after these checks have passed
that we do deep packet processing.

I still do not see where NTS keeps its MAC, and how we can do the above
validations before doing deep packet processing.

If deep packet processing is required to do NTS packet authentication,
then NTS is creating a larger DOS vector for an NTP implementation.

What other EFs are expected to be encrypted in the AEAD section?  What
should be done if encryped EFs are found to be invalid?

Are you using the "authentication tag" described in the Ciphertext
section  of 6.6 to mean the MAC?  If so, this would seem to violate the
expected behavior.

6.7 Protocol details

"In general, however, the server MUST discard any unauthenticated
 extension fields and process the packet as though they were not
 present.  Servers MAY implement exceptions to this requirement for
 particular extension fields if their specification explicitly
 provides for such."

No, overreach.  NTS has no business making these statements or
requirements.  They are properly handled elsewhere.

Under what circumstances will a client send multiple cookie placeholder EFs?

"If the server is unable to validate, ... KoD ...": This is
overloading/mis-using KoD.  What is wrong with the crypto-NAK for this
purpose?  More bluntly, since this point was not addressed from my
earlier message on the topic, this is a job for crypto-NAK, and we
should not misuse/overload KoD for this.

"Upon receiving an NTS NAK, the client MUST verify that the Unique
 Identifier matches that of an outstanding request.  If this check
 fails, the packet MUST be discarded without further processing."

I'm not sure about this.  I recall there are reasons that we might want
to update some variables even when we are going to discard a packet.  It
won't take much to verify this, but we should do it before specifying
this language.

8. IANA considerations:

Why are we requesting a dedicated TCP port for NTS-KE instead of using
TCP/123?  Please describe the pros/cons of each approach somewhere.

See above.  NTS should use exactly 1 Extension Field Type, and the UI,
Cookie, Cookie Placeholder, and AE directives should be EF Codes.

9.1 DDoS amplification:
"NTS-related extension fields included in server responses will be
 the same size as the NTS-related extension fields sent by the client."

First, how difficult will it be for a bad guy to send a large packet to
a server, thereby REQUIRING that the server respond with an
identically-sized response to the (spoofed) target?

I propose:

  NTS-related extension fields included in server responses SHOULD
  be no larger than the packets sent by the putative client.

9.3 Usage of NTP Pools:

"pool organizers will need to act as certificate authorities, regularly
 monitor the behavior of servers to which certificates have been issued,
 and promptly revoke the certificate of any server found to be serving
 incorrect time."

Inappropriate language/assumption of authority.  How about:

 Pool organizers will SHOULD act as (or in collaboration with their)
 certificate authorities, regularly monitor the behavior of servers to
 which pool certificates have been issued, and promptly revoke the
 certificate of any server found to be serving incorrect time.

10.1 Unlinkability.  I mention this here only because I'm reading the
document from start to finish.  I've discussed this before, and I still
think it's a red-herring.  It seems to me the most linkable bit of
information in a client request is the destination address.  If this
isn't the case I think we'd all benefit from a proper study of the issues.

Similarly, the claim about linkability due to mode 4 (server) responses
seems highly suspicious, because one would expect that most *all*
responses from a given server would have repeatable REFID, reftime, and
stratum.

10.2. Confidentiality.  Please.  What client-confidential information
exists in a normal NTP header that is not able to be adequately
protected right now?  When using SNTP queries with minimal data fields
one already gets all of the protections described in
ntp-data-minimization.  Limiting the specification of remediation of
this issue to the data minimization draft is ... suboptimal (I'm sure
you can think of other words to use).  The point about "Future extension
fields could hypothetically contain sensitive information" seems
implausible.  Have any such possibilities >that are appropriate for an
NTP Extension Field< packet even been considered?  But assuming there is
a way to tell NTS to send this information encrypted, that would mean
that the peer-mode DTLS
connection would have to provide encryption, and the client/server NTS
EF would have to provide an API, which has not been described here, to
contain this encrypted information.

** Editorial comments:

Please use consistent punctuation. (eg, missing period at the end of
1.1. Objectives: Identity).

1.2. Protocol Overview

"These various modes have different and contradictory requirement for
security and performance."  This is a naive observation, and is not
true.  We *always* care about performance and security.  Different modes
simply use different equations for deciding how to achieve the
performance and security goals they require.

"In order to simultaneously serve these *conflicting* requirements..."
Again, the requirements are not conflicting, they're just different,
based on the use-case.

"... NTS is structured as a suite of three protocols:"  It should be
noted that other methods to accomplish these goals are possible, and
that what is subsequently described is *one* way that is expected to
satisfy the requirements.

"The "NTS Extension Fields for NTPv4" are ..." is better now, thanks.
The phrase "cryptographically securing NTPv4" is another way to say
"offers tamper protection via MAC", right?  "Cryptographically securing"
seems too general to me, as it could easily be misconstrued to mean
"encrypted".

5. The NTS Key Establishment protocol: Should that be:

   The NTS Key Establishment (NTS-KE) protocol

Similarly, please use consistent capitalization in "NTS Key
Establishment" v. "NTS key establishment".

Ditto for "NTS-KE Record Types" v. "NTS-KE record types".

Should 'NTPv4 protocol' be 'NTPv4 Protocol' in a number of places?
There are other, similar cases (NTS-KE protocol).

6.1 Key Extraction.  Sorry - I'm not seeing the email where it was
described why 2 keys (C2S and S2C) are useful, as opposed to a single key.

6.2. Packet structure overview

NTS as described offers two types of protection, DTLS encapsulation and
NTS EFs.  Does this section apply to both?  If not, please be more clear.

NTS should use a SINGLE Extension Field type, and the different modes
should be EF Codes.  See draft-stenn-ntp-extension-fields-01.

6.5 NTS Cookie Placeholder: Will there never be a use-case for data in
the cookie placeholder?  If this is a possibility, then it would be
sufficient to change the last sentence to "The contents of the NTS
Cookie Placeholder EF's body are undefined."  The bit about length
checking is handled above this layer.

I'd find it easier to navigate the document if, instead of:

6.3 Unique ID
6.4 NTS Cookie
6.5 NTS Cookie Placeholder
6.6 NTS AEE

that we use this instead:

6.3 NTS Extension Field and EF Codes
6.3.1 Unique ID
6.3.2 NTS Cookie
6.3.3 NTS Cookie Placeholder
6.3.4 NTS AEE

It is wasteful to burn 4 EFs for NTS when we can use 1, which is how EFs
were designed to be implemented and used.

6.6: we must address RFC7822.  The padding language in this section is a
prime example of why we must rescind RFC7822 and advance
draft-stenn-ntp-extension-fields-01.

6.7 Protocol details: NTS protection applies to both DTLS and NTS-EF
traffic.  The document states that NTP over DTLS will not use NTF EFs.
Please use more precise language wherever "NTS protection" is currently
used.  Perhaps "NTS EF-protected" instead of "NTS-protected".

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!