Network Time Security for the Network Time Protocol
draft-ietf-ntp-using-nts-for-ntp-28

[Ballot comment]
Thanks for addressing my discuss points about retries recommendations!


------
Old comments for the record as only partially addressed yet:
-----

In addition to Ben's discuss point on ports which I would also like to see the answer to, one more question: My understanding is that the TCP port (123) for NTP is not used and will likely never be used in future. Why are you not using that port for NTS-KE, as NTS-KE is using TCP?

A couple more small questions:
1) Sec 4.1.3:
"The Critical Bit MUST be set."
If you set the Critical Bit for error records, that would only mean that a receiver could send another error in response to that error which again has the critical bit set which then could cause another error, and it would go on forever. Yes, this case should never happen as all its-ke implementations must support error records but maybe it's safer to just not set the critical bit?

2) Sec 4.1.4: I don't really understand the idea of the Warning record. There are no code points defined and there is no explanation given what this could be used for. Especially what should a client do that received a warning? Why is the error record not sufficient?

3) Sec 4.1.5: "  If the NTS Next Protocol Negotiation record offers Protocol ID 0 (for
  NTPv4), then this record MUST be included exactly once. "
In this case, I guess the critical bit should/MUST be also set to 1?

4) Sec 5.7:
"1280 octets is
  the minimum prescribed MTU for IPv6 and is in practice also safe for
  avoiding IPv4 fragmentation.  Nonetheless, senders SHOULD include
  fewer cookies and placeholders than otherwise indicated if doing so
  is necessary to prevent fragmentation."
RFC8085 says "For IPv4, EMTU_S is the smaller of 576 bytes and the
  first-hop MTU [RFC1122]."
Maybe it would be appropriate to note that.

[Ballot discuss]
[updated for -25]
Thank you for this document; it has been a long time coming and is much
awaited.  That said, I have a few points I'd like to discuss before I
can comfortably ballot Yes:

I'm happy to see prominent references to RFCs 7525 and 6125.
Unfortunately, merely citing RFC 6125 does not provide a usable
specification for an application to implement; we need to additionally
state what type of name (e.g., SRV-ID or DNS-ID) is used as input to the
validation process and how the application obtains that name.  Given
that we are defining a service name (and port number) for ntske, SRV-ID
might be appropriate (DNS-ID is the most common form I see consumers
of RFC 6125 using).

[Ballot discuss]
Two rather small and hopefully quick-to-address points that I think must be clarified before publication of this spec:

1) Sec 5.7: "In that
  case, it MUST be able to detect and stop looping between the NTS-KE
  and NTP servers by rate limiting the retries using e.g. exponential
  retry intervals."
Yes, rate limiting and exponential back-off is good here. However, you anyway need to define a maximum number of retries (to actually make it stop at some point) and further given some recommendation for an appropriate rate limit (e.g. initial retry after 3 seconds...?).

2) Sec 4.1.3: "      Error code 2 means "Internal Server Error".  The server MUST
      respond with this error if it is unable to respond properly due to
      an internal condition."
At least for this error, I think you need to specify what the client should do on reception. Retry? Immediately? How often? Or wait for a while?

[Ballot comment]
In addition to Ben's discuss point on ports which I would also like to see the answer to, one more question: My understanding is that the TCP port (123) for NTP is not used and will likely never be used in future. Why are you not using that port for NTS-KE, as NTS-KE is using TCP?

A couple more small questions:
1) Sec 4.1.3:
"The Critical Bit MUST be set."
If you set the Critical Bit for error records, that would only mean that a receiver could send another error in response to that error which again has the critical bit set which then could cause another error, and it would go on forever. Yes, this case should never happen as all its-ke implementations must support error records but maybe it's safer to just not set the critical bit?

2) Sec 4.1.4: I don't really understand the idea of the Warning record. There are no code points defined and there is no explanation given what this could be used for. Especially what should a client do that received a warning? Why is the error record not sufficient?

3) Sec 4.1.5: "  If the NTS Next Protocol Negotiation record offers Protocol ID 0 (for
  NTPv4), then this record MUST be included exactly once. "
In this case, I guess the critical bit should/MUST be also set to 1?

4) Sec 5.7:
"1280 octets is
  the minimum prescribed MTU for IPv6 and is in practice also safe for
  avoiding IPv4 fragmentation.  Nonetheless, senders SHOULD include
  fewer cookies and placeholders than otherwise indicated if doing so
  is necessary to prevent fragmentation."
RFC8085 says "For IPv4, EMTU_S is the smaller of 576 bytes and the
  first-hop MTU [RFC1122]."
Maybe it would be appropriate to note that.

[Ballot discuss]
Two issues I would like to discucss:

4.1.7.  NTPv4 Server Negotiation
The
  contents of the string SHALL be either an IPv4 address, an IPv6
  address, or a fully qualified domain name (FQDN).

The client MUST NOT send more than one
  record of this type.

I get there are assumptions about which address family to use for this record. Is it assumed that one the KE server will chose what address family the clien'ts request is coming in over? Do there need to be more discussion of this assumption in the document? For example an client indication of an IPv4 address can the server respond with an IPv6? And maybe even more relevant, what if the client has included an IPv6 address in the field in the request, even if the connection to the KE is over IPv4. I would appreciate some clarification or recommendation on how to select what family to use so that the protocol achieve the least amount of surprise here.


Secondly, I struggle to full understand the implementation requirements of the replay protection.

5.7:
      Exactly one Unique Identifier extension field which MUST be
      authenticated, MUST NOT be encrypted, and whose contents MUST NOT
      duplicate those of any previous request.

Is the last "MUST NOT" really a MUST NOT in the most strict sense? It could require a client to keep a history of all used Unique Identifiers since it started. I think that would be a significant state management task for the client. I would expect that a client could work well with a window of N packets, where N is in the range hundreds to thousands and using a RNG for the Unique Id field. By tracking requests sent, their timestamp and Unique Id the client wouldn't the client be able to protect against replays? Discard any unknown unique IDs, discard any second reception of Unique IDs. This also depends on that replay packets outside of the window can be detected even if the RNG generated a duplicate ID. I assume so is possible based on that the NTP timestamps that are authenticated will be outside of the window of what is acceptable and not match the request.

To summarize can we get some more clarity on how the client process of replay protection.

[Ballot comment]
Section 5.6:

The
  contents of the string SHALL be either an IPv4 address, an IPv6
  address, or a fully qualified domain name (FQDN).

The
  contents of the string SHALL be either an IPv4 address, an IPv6
  address, or a fully qualified domain name (FQDN).

This is nit-picking, but shouldn't this be explicit that the zero-padding is at the end of respective field?

[Ballot comment]
Thanks for a well-written document.  I have one small, non-blocking question:
Section 4.1.6 says, “the Critical Bit SHOULD NOT be set.”  Why “SHOULD NOT” rather than “MUST NOT”?  Under what conditions might a server set it, and why?  (Similar question for other “SHOULD NOT set” cases in the document.)

[Ballot comment]
(tried to de-duplicate COMMENTs with Ben’s)

I support Ben Kaduk’s DISCUSS position.

** Section 3. Since NTS is a green field design, is there are reason to be backward compatible to TLS version <1.3?

** Section 4.1.7.  Consider using RFC900 as a reference for IPv4 dotted decimal notation.

[Ballot discuss]
Thank you for this document; it has been a long time coming and is much
awaited.  That said, I have a few points I'd like to discuss before I
can comfortably ballot Yes:

I'm happy to see prominent references to RFCs 7525 and 6125.
Unfortunately, merely citing RFC 6125 does not provide a usable
specification for an application to implement; we need to additionally
state what type of name (e.g., SRV-ID or DNS-ID) is used as input to the
validation process and how the application obtains that name.  Given
that we are defining a service name (and port number) for ntske, SRV-ID
might be appropriate (DNS-ID is the most common form I see consumers
of RFC 6125 using).

In a related vein, if ALPN is necessary for confirming ntske operation,
it's not entirely clear to me that a dedicated port (in addition to
service name) is required, and RFC 6335 discourages fixed port numbera
llocations.  Perhaps it's not intended that DNS-SD is used to discover
NTS-KE servers, though -- there's no reference to RFC 6763 in this
document, or other discussion of server discovery that I can see.

We seem to be internally inconsistent about whether the Cookie extension
can be encrypted -- Section 5.7 says "MUST NOT be encrypted", but
Section 5.2 implies that it could be encrypted:

  Always included among the authenticated or authenticated-and-
  encrypted extension fields are a cookie extension field and a unique
  identifier extension field.  [...]

Section 7.6 says that applications for new record types need to specify
the contents of the "Set Critical Bit" field, but this field is not
included in the table of initial entries.  Additionally, there doesn't
seem to be a clear description of what the semantics of the "Set
Critical Bit" field should be.

[Ballot comment]
Section 1.1

  o  Identity: Through the use of the X.509 public key infrastructure,

It's not exactly accurate to say that there's one privileged "X.509 PKI"
(even if that would have been true about the original X.500 vision); we
have a large set of stuff on the "Web PKI" but there are other
X.509-based PKIs in use in, e.g., the cable industry.  I'd suggest
either dropping "the" or (if appropriate, which is not entirely clear)
adding "Web".

  o  Replay prevention: Client implementations may detect when a
      received time synchronization packet is a replay of a previous
      packet.

Given that a replay of time synchronization information kind of defeats
the point of a time synchronization protocol, do we want to use
something stronger than "may" here?

  o  Unlinkability: For mobile clients, NTS will not leak any
      information additional to NTP which would permit a passive
      adversary to determine that two packets sent over different
      networks came from the same client.

I guess it's kind of implicit that server mobility isn't really a thing
and thus we don't need to be concerned about linkability of servers.

  o  Non-amplification: Implementations (especially server
      implementations) may avoid acting as distributed denial-of-service
      (DDoS) amplifiers by never responding to a request with a packet
      larger than the request packet.

[similar comment about "may"]

Section 1.2

  The typical protocol flow is as follows: The client connects to an
  NTS-KE server on the NTS TCP port and the two parties perform a TLS

(Section 7.1 requests a port for "ntske"; I don't know how tightly we
need to constrain descriptive usage like this.)

  handshake.  Via the TLS channel, the parties negotiate some
  additional protocol parameters and the server sends the client a
  supply of cookies along with an IP address to the NTP server for
  which the cookies are valid.  The parties use TLS key export

nit: "IP address of the NTP server"

  phase of the protocol.  This negotiation takes only a single round
  trip, after which the server closes the connection and discards all
  associated state.  At this point the NTS-KE phase of the protocol is

nit(?): I'm not sure if there's a preference between "only takes a single
round trip" and "consists of a single request/response exchange".

  Figure 1 provides an overview of the high-level interaction between
  the client, the NTS-KE server, and the NTP server.  Note that the
  cookies' data format and the exchange of secrets between NTS-KE and
  NTP servers are not part of this specification and are implementation
  dependent.  However, a suggested format for NTS cookies is provided
  in Section 6.

This is analogous to the RFC 5077 treatment of TLS session tickets that
gives a "recommended" construction; however, while RFC 8446 to some
extent supersedes RFC 5077's specification, 8446 specifically does not
give a "recommended" construction, since there's not a whole lot that
specifically needs to be recommended.  I wonder if it would be better to
discuss this as an "example" construction rather than a "recommended"
one.

Section 3

  Since the NTS protocol is new as of this publication, no backward-
  compatibility concerns exist to justify using obsolete, insecure, or
  otherwise broken TLS features or versions.  Implementations MUST

So we can mandate TLS 1.3?
(Among other things, this would also obviate any need to worry about
requiring extended master secret before using the TLS Exporter
interface.)

  conform with [RFC7525] or with a later revision of BCP 195.  In
  particular, failure to use cipher suites that provide forward secrecy
  will make all negotiated NTS keys recoverable by anyone that gains
  access to the NTS-KE server's private key.  Furthermore:

So forward secret ciphersuites are REQUIRED?

Section 4

Is there any significance to the ordering of records within a message
(other than End of Message)?

  The NTS key establishment protocol is conducted via TCP port
  [[TBD1]].  The two endpoints carry out a TLS handshake in conformance

[See discuss point about server discovery]

  in the TLS-protected channel.  Then, the server SHALL send a single
  response followed by a TLS "Close notify" alert and then discard the
  channel state.

[side note: since we define NTS-KE to be the single request/response
pair and the response is self-framing, the close_notify is kind of
redundant.  Which is not to say that it's bad to talk about, though it
does make one wonder why we only say the server sends it and don't have
the client also send one in response.  (Note that RFC 8446 has "Each
party MUST send a "close_notify" alert before closing its write side of
the connection, unless it has already sent some error alert.")]


While the prospect of a reflection attack seens unlikely (would a
machine be acting as both NTS-KE client and server?), it may be worth
introducing some marker of whether a record is being sent by a client
vs. a server.

  For clarity regarding bit-endianness: the Critical Bit is the most-
  significant bit of the first octet.  In C, given a network buffer
  `unsigned char b[]` containing an NTS-KE record, the critical bit is
  `b[0] >> 7` while the record type is `((b[0] & 0x7f) << 8) + b[1]`.

When people use C syntax for examples we tend to ask for a reference or
at least indication of a language version, though I can't imaging this
particular aspect changing in a future version of C...

Please mention somewhere that the angle brackets in Figure 3 are used to
denote optional records.

Section 4.1.2

Just to check: because of the "close_notify" requirement, any future
"Next Protocol" is going to only be using the key material established
through this NTS-KE session, but cannot be using this TLS connection
(akin to STARTTILS ... or should I say STARTNTS?).

Section 4.1.3

What do I do if I get an Error record without the critical bit set?
Treat it as ... an error?

Section 4.1.5

The AEAD Algorithms registry just gives a listing of "raw" ciphers; do
we expect there to be a need for additional specifications that cover
how to integrate the AEAD cipher into a given NTS Next Protocol?
(Obviously this document does so for NTPv4.)

  If the NTS Next Protocol Negotiation record offers Protocol ID 0 (for
  NTPv4), then this record MUST be included exactly once.  Other
  protocols MAY require it as well.

(This seems to in practice force any future NPN protocols to not try to
define semantics for including AEAD Algorithm Negotiation more than once
... which is probably fine.)

Section 4.1.7

  The NTPv4 Server Negotiation record has a Record Type number of 6.
  Its body consists of an ASCII-encoded [ANSI.X3-4.1986] string.  The

Is the ANSI ref preferred over RFC 20?

  contents of the string SHALL be either an IPv4 address, an IPv6
  address, or a fully qualified domain name (FQDN).  IPv4 addresses

I note that up in Section 1.2 we just said that the NTS-KE server sends
"an IP address to [sic] the NTP server for which the cookies are valid",
which is internally inconsistent.

  [RFC4291] and MUST NOT include zone identifiers [RFC6874].  If a
  label contains at least one non-ASCII character, an A-LABEL MUST be
  used as defined in section 2.3.2.1 of RFC 5890 [RFC5890].

It's probably implicit, but this of course only applies in the "FQDN"
case, and the previous sentences were talking about the IP-address
cases...

      The disambiguating label string MUST be "EXPORTER-network-time-
      security/1".

I guess it's a matter of taste (though maybe we had some IAB guidance?),
but the version suffix "/1" may not be needed.

Section 5.1

My instincts are telling me to try to include, e.g., the TLS SNI value
and the NTPv4 Server/Port negotiation results in the exporter input, but
I think that is not actually needed (the TLS handshake transcript
protects the SNI value and the TLS connection itself protects the
others).

Section 5.2

  field is to enable the server to offload storage of session state
  onto the client.  The purpose of the unique identifier extension
  field is to protect the client from replay attacks.

Just to check: this is a "unique identifier" of the NTP packet (i.e., a
nonce), not a "unique identifier" of the client or some other persistent
entity?

Section 5.5

It's probably worth mentioning here that the Cookie Placeholder is
allowed to appear multiple times (Section 5.7 gives the recommended
procedure for doing so).
(Interestingly, the TLS WG is currently discussing a TLS extension to
allow a client to request a specific number of cookies on a given
handshake, which RFC 8446 left entirely to the server's discretion.)
[As another side note, this "single-use cookie with a new one returned
on each exchange" mechanism reminds me a lot of the ACME nonce usage,
though ACME places the burden of single-use on the server whereas for
NTS the client can enforce or choose to not enforce single-use.]

  prevent DDoS amplification.  The contents of the NTS Cookie
  Placeholder extension field's body are undefined and, aside from
  checking its length, MUST be ignored by the server.

It seems like whenever we leave something's contents undefined, some
clever person in the future is going to want to repurpose it for
something...if we require it to be all-zeros (or some other value) for
now, such future extensions can be more reliable.

Section 5.6

  not exceed the length of the request.  For mode 4 (server) packets,
  no Additional Padding field is ever required.  For mode 3 (client)

nit: s/ever/never/

  Senders are always free to include more Additional Padding than
  mandated by the above paragraph.  Theoretically, it could be

Is there a practical upper bound on how much padding could be included?
Would we expect servers to discard packets with "too much" additional
padding?

Section 5.7

      Exactly one Unique Identifier extension field which MUST be
      authenticated, MUST NOT be encrypted, and whose contents MUST NOT
      duplicate those of any previous request.

What's the scope of the "MUST NOT duplicate"?  Per C2S key?  Per client?

      and MUST NOT be encrypted.  The cookie MUST be one which has been
      previously provided to the client; either from the key exchange
      server during the NTS-KE handshake or from the NTP server in
      response to a previous NTS-protected NTP request.

nit: comma instead of semicolon (the second half is not a complete
sentence).

  preference.  Section 10.1 describes the privacy considerations of
  this in further detail.

nit(?): maybe "this tradeoff"?

  fields 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.  The client SHOULD NOT include more
  than seven NTS Cookie Placeholder extension fields in a request.
  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.

Choosing the number of Cooke Placeholders to include in this way can
introduce a side channel of information for (essentially) the amount of
packet loss the client is observing.  In the interest of reducing the
number of side channels available, perhaps we should give some positive
guidance to prefer encrypting the placeholders rather than leaving them
authenticated but unencrypted?

  1280 octets if no non-NTS-related extensions are used; 1280 octets is
  the minimum prescribed MTU for IPv6 and is in practice also safe for
  avoiding IPv4 fragmentation.  Nonetheless, senders SHOULD include

(If I held the pen this would be "generally safe", but I do not have
specific grounds to object to this phrasing.)


I know that RFC 5116 discusses AEAD decryption as producing either
plaintext or FAIL, but when Figure 5 has the server merely "verify time
request message", should we be saying anything about "decrypt encrypted
extension fields EF" as well?  [Similarly for the client's "verify time
response message".]

  present.  Servers MAY implement exceptions to this requirement for
  particular extension fields if their specification explicitly
  provides for such.

[the specification of the server or the specification of the extension
field?]

  Upon receiving an NTS-protected request, the server SHALL (through
  some implementation-defined mechanism) use the cookie to recover the
  AEAD Algorithm, C2S key, and S2C key associated with the request, and
  then use the C2S key to authenticate the packet and decrypt the
  ciphertext.  If the cookie is valid and authentication and decryption
  succeed, the server SHALL include the following extension fields in
  its response:

[This is not consistent with the RFC 5116 AEAD terminology, though it's
hard to make a strong case that it needs to be.]

  The server MAY include additional (non-NTS-related) extension fields
  which MAY appear prior to the NTS Authenticator and Encrypted
  Extension Fields extension field (therefore authenticated but not
  encrypted), within it (therefore encrypted and authenticated), or
  after it (therefore neither encrypted nor authenticated).  In
  general, however, the client MUST discard any unauthenticated
  extension fields and process the packet as though they were not
  present.  Clients MAY implement exceptions to this requirement for
  particular extension fields if their specification explicitly
  provides for such.

[same as for the other direction]

  If the NTP server has previously responded with authentic NTS-
  protected NTP packets (i.e., packets containing the NTS Authenticator
  and Encrypted Extension Fields extension field), the client MUST

I do see "authentic" outside the parenthetical, but still wonder if
"authentic" or "properly validated" or something should also appear
within the parenthetical.

  protocol upon forced disassociation from an NTP server.  In that
  case, it MUST be able to detect and stop looping between the NTS-KE
  and NTP servers by rate limiting the retries using e.g. exponential
  retry intervals.

[I frequently express a desire to see the base of the exponent indicated
when "exponential retry intervals" are specified, though it does not
seem mandatory for correcness of operation here.]

Section 6

  nonce reuse.  It need not be the same as the one that was negotiated
  with the client.  Servers should randomly generate and store a master
  AEAD key `K`. Servers should additionally choose a non-secret, unique

And in general should be the same for all cookies generated by a given
server?
Also, we should say that 'K' should (MUST?) not be used for any other
purpose.

  periods prior.  Servers should continue to accept any cookie
  generated using keys that they have not yet erased, even if those

nit: "been erased"

  function of its predecessor.  A recommended concrete implementation
  of this approach is to use HKDF [RFC5869] to derive new keys, using
  the key's predecessor as Input Keying Material and its key identifier
  as a salt.

Do we need to say to generate the appropriate amount of output material
from HKDF as needed for the next-generation key?  (I kind of hope not,
but...)

  The cookie should consist of the tuple `(I,N,C)`.

Are 'I' and 'N' fixed-length or length-prefixed?

  and nonce `N` with no associated data.  If decryption or verification
  fails, reply with an NTS NAK.  Otherwise, parse out the contents of

[same comment about RFC 5116 terminology]

Section 7.2

In a similar vein as my comment on the
"EXPORTER-network-time-security/1" string, perhaps the "/1" is not
necessary here?

Section 7.3

I will send a note to the TLS WG giving them a heads-up about the
"Recommended" value of "Y", though my sense is that this should be in
keeping with the spirit of recommended values.

Section 9

We should probably have some discussion of the consequences of
compromise of the server's cookie-encryption key.  Possibly also for
when the key associated with a cookie is compromised from a client,
though if cookies are single-use the scope may be quite limited.  (That
is, since we are using the shared symmetric key for authentication by
virtue of "I didn't send it so it must be from the other party that has
the key".)

Section 9.2

  NTS users should also consider that they are not fully protected
  against DDoS attacks by on-path adversaries.  In addition to dropping
  packets and attacks such as those described in Section 9.5, an on-
  path attacker can send spoofed kiss-o'-death replies, which are not
  authenticated, in response to NTP requests.  This could result in

Wouldn't these on-path attacks just be DoS attacks, not DDoS ones?

  significantly increased load on the NTS-KE server.  Implementers have
  to weigh the user's need for unlinkability against the added
  resilience that comes with cookie reuse in cases of NTS-KE server
  unavailability.

It's perhaps worth mentioning the requirement for kiss-o'-death replies
to echo the message identifier once a server is known to have sent valid
NTS-protected messages, which limits the scope of this attack to on-path
attackers.

Section 9.3

It might be worth some discussion of the potential tradeoffs involved in
encoding a client IP address into a cookie, with respect to allowing for
some form of source-address validation (and thus protection against
serving as a DDoS reflector).  QUIC, for example, has facility for
encoding source-address validation state into cookie-like artifacts.
Such IP address recording comes with concordant privacy and tracking
considerations, though (hence "tradeoffs").

Additionally, it seems that if the "NTP Server Negotiation" record is
optional for the client to send but can be set by the server, that would
result in some modest packet expansion, which would be topical to
mention here.

Section 9.5

  mitigate this attack.  However, the maximum error that an adversary
  can introduce is bounded by half of the round trip delay.

Half of the round-trip after the delay attack or in its absence?

Section 9.6

  At various points in NTS, the generation of cryptographically secure
  random numbers is required.  Whenever this draft specifies the use of

The string "random" appears only in the construction of the unique
identifier and the non-normative recommended cookie construction, and
the RFC 5116 recommended nonce construction also takes a random input;
do we want to mention specific examples instead of or in addition to
saying "various points"?  (I might consider mentioning that the SIV mode
helps reduce the dependence on strong random numbers as wel.)

Section 9.7

Is there anything to say about a target end-state where some peers can
successfully require NTS for all connections (i.e., no fallback of any
sort)?

  For the reasons described here, implementations SHOULD NOT revert
  from NTS-protected to unprotected NTP with any server without
  explicit user action.

Which would then force a choice between tolerating bad time and reusing
cookies, until user action can be obtained?

Section 10.1

  The unlinkability objective only holds for time synchronization
  traffic, as opposed to key exchange traffic.  This implies that it
  cannot be guaranteed for devices that function not only as time
  clients, but also as time servers (because the latter can be
  externally triggered to send authentication data).

Are we just talking about the TLS server certificate?

Section 12.1

I'm not sure that a normative reference is needed for "MUST NOT do this"
(to RFC 6874).

RFC 7507 seems used only in the definition of SCSV, which is itself
unused in the document.

Section 12.2

Why is RFC 5280 only informative but RFC 6125 is normative?

The "SHALL" regarding HKDF usage in TLS 1.3 exporters would seem to make
RFC 5869 a normative reference per
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/,
though in my opinion the RFC 8446 reference would suffice for that
usage.


Also, Daniel should update (or remove) the address in his Author entry.

[Ballot comment]
Thank you for the work put into this document. It is easy to read (and this is important) and it has multiple implementations. Section 9.4 "Initial Verification of Server Certificates" is indeed a real chicken and egg issue and quite classical. I am also trusting the security AD and SECDIR for the security aspects of the protocol.

Please find below some non-blocking COMMENTs and NITs. An answer will be appreciated though ;-)

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1.1 --
Authentication is of course a desirable property but I would have assumed that the time accuracy is even more important. A shift in time -- even minor -- by one compromised party would even be more important.

-- Section 1.2 --
Does NTP have a "a broadcast mode" or "a multicast mode" ? Notably as the former does not exist for IPv6 ;-)

Is it really true that "it is harmless for stateless servers to process replayed packets" as it will have an impact on the server CPU even if stateless. Obviously, a DoS on a stateless server is less effective but writing "harmless" is too strong IMHO.

In Figure 1, should there be a comma between "Shared cookie" and "encryption parameters" between NTS-KE & NTP servers ?

-- Section 3 --
I really wonder why TLS 1.3 is not a MUST (e.g., AFAIK TLS 1.3 is supported by openssl) but I will trust the security AD on this topic.

-- Section 4 --
What was the reasoning behind the decision of not using a simple REST API here? This exchange is executed once, so, the overhead is not really important.

-- Section 4.1 --
Is there a specific order for the record? (except for the 'end of message') ?

-- Section 4.1.1. --
What is the expected behavior of the NTS-KE client/server when this record is not the last one or is missing?

-- Section 4.1.3 & 4.1.4 --
Should there be a IANA registry for those error / warning codes? Esp if the record type can be extended via IANA registry so new error / warning case will be required ?

-- Section 4.1.7 --
While I am a little surprised to see IPv4/IPv6 addresses transmitted as ASCII strings, please also refer to RFC 5952 for the canonical representation of an IPv6 address.

The sentence "If a label contains at least one non-ASCII character, ..." probably applies to the FQDN but it would be clearer to say so.

Should the FQDN be terminated by a final dot ?

What is the expected behavior of the client when the FQDN has several IPv4 and several IPv6 addresses ?

Is it expected that the FQDN of the NTP servers can resolve to several IP addresses based on availability, load balancing, or client mobility ? If so, how are cookies synchronized? Else, let's be specific in the document.


== NITS ==

-- Section 7.6 --
The table will gain clarity by adding an empty line between entries.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ntp-using-nts-for-ntp-22. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are nine actions which we must complete.

First, in the Service Name and Transport Protocol Port Number Registry page located at:

https://www.iana.org/assignments/service-names-port-numbers

IANA will assign a port number for ntske. An expert review will be requested for the port request. The IANA state for the document will be set to "IANA NOT OK" until the port review is completed and approved.

Second, in the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

a new registration is to be made as follows:

Protocol: Network Time Security Key Establishment, version 1
Identification Sequence: 0x6E 0x74 0x73 0x6B 0x65 0x2F 0x31 ("ntske/1")
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, the IESG-designated experts for the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs have asked that you send a review request to the mailing list tls-reg-review@ietf.org. This review must be completed before the document's IANA state can be changed to "IANA OK."

Third, in the TLS Exporter Labels registry on the Transport Layer Security (TLS) Parameters registry page located at:

https://www.iana.org/assignments/tls-parameters/

a new registration is to be made as follows:

Value: EXPORTER-network-time-security/1
DTLS-OK: Y
Recommended: Y
Reference: [ RFC-to-be;Section 4.2 ]
Note:

As this also requests registrations in an Expert Review (see RFC 8126) registry, the IESG-designated experts for the TLS Exporter Labels have asked that you send a review request to the mailing list tls-reg-review@ietf.org. This review must be completed before the document's IANA state can be changed to "IANA OK."

Fourth, in the NTP Kiss-o'-Death Codes registry on the Network Time Protocol (NTP) Parameters registry page located at:

https://www.iana.org/assignments/ntp-parameters/

a new registration is to be made as follows:

Code: NTSN
Meaning: Network Time Security (NTS) negative-acknowledgment (NAK)
Reference: [ RFC-to-be; Section 5.7 ]

Fifth, in the NTP Extension Field Types Registry also on the Network Time Protocol (NTP) Parameters registry page located at:

https://www.iana.org/assignments/ntp-parameters/

four new field types are to be registered as follows:

Field Type: [ TBD-at-Registration ]
Meaning: Unique Identifier
Reference: [ RFC-to-be; Section 5.3 ]

Field Type: [ TBD-at-Registration ]
Meaning: NTS Cookie
Reference: [ RFC-to-be; Section 5.4 ]

Field Type: [ TBD-at-Registration ]
Meaning: NTS Cookie Placeholder
Reference: [ RFC-to-be; Section 5.5 ]

Field Type: [ TBD-at-Registration ]
Meaning: NTS Authenticator and Encrypted Extension Fields
Reference: [ RFC-to-be; Section 5.6 ]

Sixth, a new registry will be created called the Network Time Security Key Establishment Record Types Registry.

IANA QUESTION --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry contains values between 0-32767. The registration policy for the new registry is as follows (as defined in RFC8126):

0-1023: IETF Review
1024-16383: Specification Required
16384-32767: Private and Experimental Use

There are initial registrations in the new registry as follows:

+-------------+-------------------------+---------------------------+
| Record Type | Description | Reference |
| Number | | |
+-------------+-------------------------+---------------------------+
| 0 | End of Message | [ RFC-to-be ], Section |
| | | 4.1.1 |
| 1 | NTS Next Protocol | [ RFC-to-be ], |
| | Negotiation | Section 4.1.2 |
| 2 | Error | [ RFC-to-be ], Section |
| | | 4.1.3 |
| 3 | Warning | [ RFC-to-be ], Section |
| | | 4.1.4 |
| 4 | AEAD Algorithm | [ RFC-to-be ], Section |
| | Negotiation | 4.1.5 |
| 5 | New Cookie for NTPv4 | [ RFC-to-be ], Section |
| | | 4.1.6 |
| 6 | NTPv4 Server | [ RFC-to-be ], Section |
| | Negotiation | 4.1.7 |
| 7 | NTPv4 Port Negotiation | [ RFC-to-be ], Section |
| | | 4.1.8 |
| 8-16383 | Unassigned | |
| 16384-32767 | Reserved for Private & | [ RFC-to-be ] |
| | Experimental Use | |
+-------------+-------------------------+---------------------------+

Seventh, a new registry is to be created called the Network Time Security Next Protocols Registry.

IANA QUESTION --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry contains values between 0-65535. The registration policy for the new registry is as follows (as defined in RFC8126):

0-1023: IETF Review
1024-32767: Specification Required
32768-65535: Private and Experimental Use

There are initial registrations in the new registry as follows:

+-------------+-------------------------------+---------------------+
| Protocol ID | Protocol Name | Reference |
+-------------+-------------------------------+---------------------+
| 0 | Network Time Protocol version | [ RFC-to-be ] |
| | 4 (NTPv4) | |
| 1-32767 | Unassigned | |
| 32768-65535 | Reserved for Private or | Reserved by |
| | Experimental Use | [ RFC-to-be ] |
+-------------+-------------------------------+---------------------+

Eighth, a new registry is to be created called the Network Time Security Error Codes registry.

IANA QUESTION --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry contains values between 0-65535. The registration policy for the new registry is as follows (as defined in RFC8126):

0-1023: IETF Review
1024-32767: Specification Required
32768-65535: Private and Experimental Use

There are initial registrations in the new registry as follows:

+-------------+------------------------------+----------------------+
| Number | Description | Reference |
+-------------+------------------------------+----------------------+
| 0 | Unrecognized Critical | [ RFC-to-be ], |
| | Extension | Section 4.1.3 |
| 1 | Bad Request | [ RFC-to-be ], |
| | | Section 4.1.3 |
| 2 | Internal Server Error | [ RFC-to-be ], |
| | | Section 4.1.3 |
| 3-32767 | Unassigned | |
| 32768-65535 | Reserved for Private or | Reserved by |
| | Experimental Use | [ RFC-to-be ] |
+-------------+------------------------------+----------------------+

Ninth, a new registry is to be created called the Network Time Security Warning Codes registry.

IANA QUESTION --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry contains values between 0-65535. The registration policy for the new registry is as follows (as defined in RFC8126):

0-1023: IETF Review
1024-32767: Specification Required
32768-65535: Private and Experimental Use

There are initial registrations in the new registry as follows:

+-------------+-------------------------------+---------------------+
| Number | Description | Reference |
+-------------+-------------------------------+---------------------+
| 0-32767 | Unassigned | |
| 32768-65535 | Reserved for Private or | Reserved by |
| | Experimental Use | [ RFC-to-be ] |
+-------------+-------------------------------+---------------------+

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-02-28):

From: The IESG
To: IETF-Announce
CC: ntp@ietf.org, odonoghue@isoc.org, Karen O'Donoghue , draft-ietf-ntp-using-nts-for-ntp@ietf.org, ntp-chairs@ietf.org, suresh@kaloom.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Network Time Security for the Network Time Protocol) to Proposed Standard


The IESG has received a request from the Network Time Protocol WG (ntp) to
consider the following document: - 'Network Time Security for the Network
Time Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-02-28. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This memo specifies Network Time Security (NTS), a mechanism for
  using Transport Layer Security (TLS) and Authenticated Encryption
  with Associated Data (AEAD) to provide cryptographic security for the
  client-server mode of the Network Time Protocol (NTP).

  NTS is structured as a suite of two loosely coupled sub-protocols.
  The first (NTS-KE) handles initial authentication and key
  establishment over TLS.  The second handles encryption and
  authentication during NTP time synchronization via extension fields
  in the NTP packets, and holds all required state only on the client
  via opaque cookies.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc5297: Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES) (Informational - IETF stream)

This is the publication request and document shepherd write up for:

Network Time Security for the Network Time Protocol
draft-ietf-ntp-using-nts-for-ntp-20

Prepared by: Karen O’Donoghue, 7 November 2019 

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard

This is a new badly needed security mechanism for client/server modes of service for NTP. It is based on TLS. As such, it should be Standards Track, and it has been proposed as such.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This memo specifies Network Time Security (NTS), a mechanism for    using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the Network Time Protocol (NTP).

NTS is structured as a suite of two loosely coupled sub-protocols. The first (NTS-KE) handles initial authentication and key establishment over TLS.  The second handles encryption and authentication during NTP time synchronization via extension fields in the NTP packets, and holds all required state only on the client via opaque cookies.

Working Group Summary:

The document has clear working group consensus for publication, and has been reviewed by several WG participants since its initial adoption as a working group item.

Document Quality:
 
This document has been reviewed and revised several times during its development. There were no specific external expert reviews conducted; however, security area review was specifically solicited.
 
Personnel: 

Karen O'Donoghue is acting as the Document Shepherd.  Suresh Krishnan is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
 
The document shepherd has followed the working group process and reviewed the final document and feels this document is more than ready for IESG review.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
 
The document shepherd does not have any concerns about the reviews that were performed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

This document does not require any special reviews beyond those planned during the IESG review process.
 
(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
 
The Document Shepherd is comfortable with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

There are no IPR filings on this document. The document shepherd has requested confirmation from all the authors that they are in full conformance with the provisions of BCP78 and BCP79 with respect to IPR disclosures.
 
(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There is no IPR disclosures for this document.
 
(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The document represents strong WG consensus. It has been evolving in the working group for a number of years. There is one working group member who has not agreed with the working group consensus. This is based on the fact that the solution only provides for the client/server modes of NTP operation. However, the remaining working members have agreed that the vast majority of NTP usage is actually client/server mode, and there is a strong need to get this solution out there. Additionally there are multiple independent implementations and two public servers supporting NTS at this point in time.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.

There have been no threats of anyone appealing the documents.
 
(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The document shepherd ran ID nits and found a few minor issues that can be fixed on the next iteration.

1 Error:
One normative reference to an informational RFC: RFC 5297
This was intentional and will remain as specified given that the referenced document is for SIV, a block cipher mode of operation.

1 Warning:
One FQDN warning… (will be spelled out)

4 Comments:
Two uses of square brackets in equations that trigger the “looks like a reference but probably isn’t” comment
An information reference that needs to be updated RFC 5077 → RFC 8446
Date on document is old (delay in shepherd writeup)

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There are no formal review criteria for this document.
 
(13) Have all references within this document been identified as either normative or informative?

All references are tagged as normative or informative.
 
(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references are completed.
 
(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There is one downref flagged (RFC 5297), but this was intentional and will remain as specified given that the referenced document is for SIV, a block cipher mode of operation. This is IETF standard practice for crypto documents.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document does not change the status of any existing RFCs.
 
(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

This document requests allocations from five existing registries along with the creation of four new registries. All the actions specified are consistent with the document and reasonably specified.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The new registries all require either IETF review or specification required.  

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There were no automated checks on formal language.

This is the publication request and document shepherd write up for:

Network Time Security for the Network Time Protocol
draft-ietf-ntp-using-nts-for-ntp-20

Prepared by: Karen O’Donoghue, 7 November 2019 

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard

This is a new badly needed security mechanism for client/server modes of service for NTP. It is based on TLS. As such, it should be Standards Track, and it has been proposed as such.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This memo specifies Network Time Security (NTS), a mechanism for    using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the Network Time Protocol (NTP).

NTS is structured as a suite of two loosely coupled sub-protocols. The first (NTS-KE) handles initial authentication and key establishment over TLS.  The second handles encryption and authentication during NTP time synchronization via extension fields in the NTP packets, and holds all required state only on the client via opaque cookies.

Working Group Summary:

The document has clear working group consensus for publication, and has been reviewed by several WG participants since its initial adoption as a working group item.

Document Quality:
 
This document has been reviewed and revised several times during its development. There were no specific external expert reviews conducted; however, security area review was specifically solicited.
 
Personnel: 

Karen O'Donoghue is acting as the Document Shepherd.  Suresh Krishnan is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
 
The document shepherd has followed the working group process and reviewed the final document and feels this document is more than ready for IESG review.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
 
The document shepherd does not have any concerns about the reviews that were performed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

This document does not require any special reviews beyond those planned during the IESG review process.
 
(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
 
The Document Shepherd is comfortable with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

There are no IPR filings on this document. The document shepherd has requested confirmation from all the authors that they are in full conformance with the provisions of BCP78 and BCP79 with respect to IPR disclosures.
 
(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There is no IPR disclosures for this document.
 
(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The document represents strong WG consensus. It has been evolving in the working group for a number of years. There is one working group member who has not agreed with the working group consensus. This is based on the fact that the solution only provides for the client/server modes of NTP operation. However, the remaining working members have agreed that the vast majority of NTP usage is actually client/server mode, and there is a strong need to get this solution out there. Additionally there are multiple independent implementations and two public servers supporting NTS at this point in time.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.

There have been no threats of anyone appealing the documents.
 
(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The document shepherd ran ID nits and found a few minor issues that can be fixed on the next iteration.

1 Error:
One normative reference to an informational RFC: RFC 5297

1 Warning:
One FQDN warning… (will be spelled out)

4 Comments:
Two uses of square brackets in equations that trigger the “looks like a reference but probably isn’t” comment
An information reference that needs to be updated RFC 5077 → RFC 8446
Date on document is old (delay in shepherd writeup)

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There are no formal review criteria for this document.
 
(13) Have all references within this document been identified as either normative or informative?

All references are tagged as normative or informative.
 
(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references are completed.
 
(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downrefs.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document does not change the status of any existing RFCs.
 
(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

This document requests allocations from five existing registries along with the creation of four new registries. All the actions specified are consistent with the document and reasonably specified.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The new registries all require either IETF review or specification required.  

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There were no automated checks on formal language.

This is the publication request and document shepherd write up for:

Network Time Security for the Network Time Protocol
draft-ietf-ntp-using-nts-for-ntp-20

Prepared by: Karen O’Donoghue, 7 November 2019 

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard

This is a new badly needed security mechanism for client/server modes of service for NTP. It is based on TLS. As such, it should be Standards Track, and it has been proposed as such.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This memo specifies Network Time Security (NTS), a mechanism for    using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the Network Time Protocol (NTP).

NTS is structured as a suite of two loosely coupled sub-protocols. The first (NTS-KE) handles initial authentication and key establishment over TLS.  The second handles encryption and authentication during NTP time synchronization via extension fields in the NTP packets, and holds all required state only on the client via opaque cookies.

Working Group Summary:

The document has clear working group consensus for publication, and has been reviewed by several WG participants since its initial adoption as a working group item.

Document Quality:
 
This document has been reviewed and revised several times during its development. There were no specific external expert reviews conducted; however, security area review was specifically solicited.
 
Personnel: 

Karen O'Donoghue is acting as the Document Shepherd.  Suresh Krishnan is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
 
The document shepherd has followed the working group process and reviewed the final document and feels this document is more than ready for IESG review.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
 
The document shepherd does not have any concerns about the reviews that were performed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

This document does not require any special reviews beyond those planned during the IESG review process.
 
(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
 
The Document Shepherd is comfortable with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

There are no IPR filings on this document. The document shepherd has requested confirmation from all the authors that they are in full conformance with the provisions of BCP78 and BCP79 with respect to IPR disclosures.
 
(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There is no IPR disclosures for this document.
 
(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The document represents strong WG consensus. It has been evolving in the working group for a number of years. There is one working group member who has not agreed with the working group consensus. This is based on the fact that the solution only provides for the client/server modes of NTP operation. However, the remaining working members have agreed that the vast majority of NTP usage is actually client/server mode, and there is a strong need to get this solution out there. Additionally there are multiple independent implementations and two public servers supporting NTS at this point in time.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.

There have been no threats of anyone appealing the documents.
 
(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The document shepherd ran ID nits and found a few minor issues that can be fixed on the next iteration.

1 Error:
One normative reference to an informational RFC: RFC 5297

1 Warning:
One FQDN warning… (will be spelled out)

4 Comments:
Two uses of square brackets in equations that trigger the “looks like a reference but probably isn’t” comment
An information reference that needs to be updated RFC 5077 → RFC 8446
Date on document is old (delay in shepherd writeup)

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There are no formal review criteria for this document.
 
(13) Have all references within this document been identified as either normative or informative?

All references are tagged as normative or informative.
 
(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references are completed.
 
(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downrefs.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document does not change the status of any existing RFCs.
 
(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

This document requests allocations from five existing registries along with the creation of four new registries. All the actions specified are consistent with the document and reasonably specified.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The new registries all require either IETF review or specification required.  

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There were no automated checks on formal language.