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

[Dieter Sibold <[e-mail]>]

Hi Marcus,
thanks for your comments. I have a short query with regards to the last sentence in the first bullet point. I suppose that you meant to write ... should not decrease the protocol's ... instead of ... should not increase the protocol's ... Otherwise, I would not understand the objective.

I'm going to review the other bullet points later.

- Dieter

Am 15.11.18, 23:00 schrieb "ntp im Auftrag von Marcus Dansarie" <[e-mail] im Auftrag von [e-mail]>:

    All,
    
    Ragnar and I spent a couple of hours yesterday going over NTS4NTP draft
    14. Overall, we are very happy with the current state of the draft. Our
    remaining concerns and a few general comments are as follows:
    
    * In Section 1.1, we would still like resilience to be an express
    objective of NTS. A possible wording could be "Attacks on or faults in
    parts of the NTS infrastructure should not completely prohibit clients
    from performing time synchronization. In particular, security
    enhancements to the NTP protocol should not increase the protocol's
    ability to withstand attacks."
    
    * Re Section 3, we still feel that TLS 1.3 should be the lowest
    acceptable TLS version. It is certainly true that requiring TLS 1.3
    would probably limit short term adaption of NTS. Our opinion, however,
    is that concerns for for the short term should not take priority over
    the long term where this could lead to servers having to support TLS 1.2
    for a long time if TLS 1.2-only client implementations were to emerge
    after the draft's adaption as an RFC.
    
    * Our suggested NTP Server Negotiation record from draft-dansarie-nts-00
    has been reworked by Daniel Franke into Sections 4.1.7 and 4.1.8
    following comments in previous WG meetings. After thorough discussion,
    Ragnar and I now agree that the design in current draft is sound and
    that there is no need for the NTS-KE protocol to support lists of
    preferred/assigned servers in server/port negotiation records. Such
    lists would add to protocol complexity while only satisfying a fringe
    requirement that can be achieved on the implementation side without this
    addition. We only have one minor comment to the wording: In Section
    4.1.7, paragraph 2: "If no record of this type is sent, the client SHALL
    interpret this [...]", we believe that SHALL is to strong of a
    requirement and that a SHOULD would suffice.
    
    * In Section 5.6, we support the addition of an additional padding field
    and the reasoning behind it.
    
    * In Section 7.1, the service name has been changed to "ntske". We
    support this. The section reserves a TCP port only for NTS-KE. It has
    been suggested to us that it is customary to register both TCP and UDP
    ports with the same number, but we're unsure what the current practice
    is. Considering that NTP's registered port is in the system port range,
    we think that we should try to get an NTS-KE port in the same range,
    unless there are strong reasons not to.
    
    * In Section 9.3, it is suggested that clients should "not process time
    packets from servers if the time computed from them falls outside the
    validity period of the server's certificate." We believe that there is a
    risk that this could be interpreted as meaning that clients should
    reperform an NTS-KE handshake upon expiry of the certificate that was
    used by the NTS-KE server to provide the client with its initial supply
    of cookies. In the worst case, this could lead to an accidental DoS
    attack as many clients try to perform a new NTS-KE handshake at the
    expiry time of a server's old certificate. We suggest adding a sentence
    like "Clients SHOULD NOT perform a new NTS-KE handshake solely based on
    the fact that the certificate used by the NTS-KE server in a previous
    handshake has expired, if the client has previously received valid NTS
    protected NTP replies that lie within the certificate's validity time."
    
    * Since there is a current draft that attempts to solve the problem
    described in Section 9.4, adding a reference there to
    draft-schiff-ntp-chronos-01 could be a good idea.
    
    In conclusion: We have no major objections to the draft at this point.
    With the exception of our comment on Section 9.3, none of our comments
    are of great importance to us and we will yield if there is no
    agreement. Our concerns regarding Section 9.3 need to be addressed in
    one way or another.
    
    We would like to thank everyone who have contributed to the draft and
    made the effort to read and comment on it. We look forward to your
    comments on our suggestions.
    
    Kind regards,
    Marcus Dansarie and Ragnar Sundblad
    
    _______________________________________________
    ntp mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/ntp