Re: [Ntp] comments on draft-ietf-ntp-using-nts-for-ntp-23

[Sandra Murphy <[e-mail]>]

Here are my general comments and my responses.  As for the detailed comments, I have added the authors' github issue number to each.  Where one of the general comments duplicates one of the detailed comments, I note that, and do not repeat the response.

    Section 1 makes it clear that there is an intentional separation between the
    NTS-KE server and the NTP server, although it is allowed that both services
    could be resident on the same host.  Figure 1 also makes it appear that the
    NTS-KE server may be associated with a large number of NTP servers, with
    unspecified means of communicating between them.  Reading through, I was
    struck by how much the NTS-KE server must know about the NTP server - in
    Section 4.1.5 what algorithms it would support, in Section 6 the keying
    material it would accept.  I was puzzled at how this could work in the
    post.ntp.org set of volunteer NTP servers.  Then in Section 6, I saw a
    reference to “load-balanced cluster”, which would easily account for the
    NTS-KE server’s knowledge of the NTP servers’ configurations.  More
    explanations of the supportable (current and potential) architectures would be very helpful.
    (github issue #65)

The working group has begun work on the use of NTS with the NTP pool (pool.net.org).  That work could be what I was looking for here.

I accept the v26 text as is.

-----------------------------

    I believe it would be helpful for the implementers to have an explicit
    list of what the NTS-KE server must know about the NTP servers (address,
    algorithms supported, shared keys in use, cookie construction, protocol
    IDs accepted, anything else?) and what the communication between the NTS-KE
    server and the NTP server must provide (what Figure 1 calls “Shared cookie encryption parameters”).
    (github issue #66)

I still think that would be a boon to implementers.  I had in mind something like the following (with any additions of something I missed.)

Implementers should note that the NTS-KE server must have knowledge, in some way, of the following information about the NTP servers it supports:
- NTS enabled
- IP address
- list of Protocol ID's accepted
- list of AEAD algorithms accepted
- the NTP server's cookie format and content
- the AEAD algorithm to use in protecting the cookie (generally)
- an AEAD key and parameters for the protection of the cookie (generally)
- for those that support Section 6's suggested mechanism, the NTP server's key rotation and expiration schedules

The authors responded that this was implementation dependent.  Eric Vyncke and I noted on the mailing list that how this information is known is implementation dependent, but what must be known is not.

The list is derived from various places in the existing text, but assembling the information in one point in the text would IMHO be a benefit to implmenters who will have to decide on the means of getting this information known.

-----------------------------

    Some of the text concerns the interactions with the NTS-KE server, some
    concerns the interactions with the NTP server.  The word “server” is used
    throughout.  There are cases where it is not clear which type of server is
    meant from context.
    (github issue #67)

The v26 text changes the one place that I noted a potential ambiguity.

I accept the v26 text

-----------------------------

    I found several cases where I was not sure what the error conditions should
    be handled, when requirements are not met, when an exchange fails, when an
    error condition is received, etc.  In some sections, the receiver’s action
    upon receiving one message is explained but for other messages is not.
    (github issue #68)

This was a general comment, and in most places the authors response was that it is implementation dependent.  However, in some cases the implementation response to error or failures could result in additional load on either the NTS-KE sever or the NTP server.  Perhaps a general statement in the security considerations section would be useful and help avoid implementation behaviors that would be harmful.

Like, maybe, something similar to the following could be considered:

There are various places in this document where message errors or failures might be detected by the recipient. Where the response is left to implementation choice, implementers are urged to consider the potential for their implementation's behavior to overload the NTS-KE server or NTP server.  Consider, for example, the discussion of retrying the NTS-KE protocol in Section 5.7.  The implementer's choices must also be guided by the intended application, in choosing outcomes that might range over abandoning time synchronization, accepting insecure time, retrying attempts to achieve secure time synchronization, aborting the application, etc.

-----------------------------

    Normative language: There are places where the text says “should” not
    “SHOULD” and it was not clear the RFC2119 language was intended.  In
    particular, Section 6 uses “should” many times.  Perhaps that was
    intentional since this section is not normative.  I’m not sure what should
    (sic) be the usage in that case.  “In general” appears many times, which
    begs the question of when it is or is not the case.  On page 21, the text
    says “In general, however, the server MUST”.  I’m not sure what that means
    to an implementer.  The following language talks about exceptions, so
    perhaps the “In general” means “where there is no exception”.
    (github issue #69) duplicates detailed comment issues #53 and #56

-----------------------------

    The document sets up an IANA registry for the Protocol ID.  Is it necessary
    to stipulate what a specification of a new Protocol ID must include?  Must it include a cookie format, for example?
    (github issue #70) duplicate of detailed comments issue #49

-----------------------------

    On page 21, the caption for Figure 5 should be “NTS-protected NTP Time
    Synchronization Messages”.  It is an NTP exchange, not an NTS exchange.
    (github issue #71) duplicate of detailed comments issue #51

-----------------------------

    Section 9.4 page 36 - Is there a reference for “NTP_PHASE_MAX?”  A web
    search found only references to this draft and to a “kernel constant” in
    various *nx man pages.
    (github issue #72) duplicate of detailed comments issue #61

-----------------------------

    In Section 6, the identifier “I” is used as a salt.  RFC5869 says the salt
    is random.  Should the text about choosing the “non-secret, unique”
    identifier mention random / unpredictable as well?
    (duplicate of detailed comments issue #57)

-----------------------------

    Section 9.7 NTS Stripping talks about the client being deceived into
    reverting to plain NTP.  There’s no discussion of the server being deceived
    into responding with plain NTP.  An adversary who stripped the NTS
    extensions from the a NTP request would lead the server to reply without the
    expected NTS extensions in the response.  What should/would the client do if
    it receives a non-NTS enhanced response to a NTS enhanced request?
    (github issue #64)

v26 now has a sentence:

                                          In particular, the client MUST
   discard unprotected responses to NTS-protected requests.

v26 addresses my comment.


-----------------------------