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

[Dieter Sibold <[e-mail]>]

Hi Marcus,

thanks very much for your thoughts and comments. See my comments inline.

Am 19.11.18, 22:07 schrieb "ntp im Auftrag von Marcus Dansarie" <[e-mail] im Auftrag von [e-mail]>:

    All,
    
    I spent some time this weekend thinking some more about
    draft-ietf-ntp-using-nts-for-ntp-14, so here's a reply to myself with
    some more points. The large number of points may seem like harsh
    criticism of the draft, but that is not my intent. The draft is good,
    well written and a result of the hard work of everyone involved.
    
    * The security of many other network protocols depends on having a
    correct perception of time. For that reason, NTP is very attractive as
    an attack vector. Table I in [1] contains a summary of protocols that
    depend on correct time for security. I would also like to recommend
    reading [1] in its entirety as it contains a good summary of attacks on
    current NTP, many of which NTS seeks to prevent.

Whereas I agree with this statement I'm not sure if I understand your intention. Do you want to add language to the draft that recommends the reading of [1]? 
    
    * The security of NTS is entirely dependent on the client correctly
    verifying the KE-server's certificate and trust chain. This is made
    clear in Section 9.3, but I believe it is important enough that Section
    3 needs to contain a reference there. It could read something like: "All
    implementations are REQUIRED to implement the measures described in
    Section 9.3, as this is critical to the security of the protocol."
    Furthermore, I think Section 9.3 should have mandatory requirements for
    certificate verification. At the very least, this would have a MUST for
    following the requirements in RFC 5280 and RFC 6125. There are some
    other measures that could be added as well, such as requiring clients to
    perform OCSP checking (though there could be privacy implications to
    this) or strictly verifying the OCSP Must Staple flag if it is present.
    "Initial" should also be removed removed from the heading of Section 9.3.

I agree that implementations shall implement the measures described in 9.3. Therefore the REQUIRED is from my point of view ok. I'm not sure if we should mandate that a client is doing OCSP. I would think this should be an operational choice. We could formulate this as an recommendation. Why removing "Initial" from the heading?
    
    * If we settle on TLS 1.2 as the minimum requirement, we should only
    allow perfect forward secrecy (PFS) suites to be negotiated in the TLS
    handshake. Otherwise, the loss of a certificate private key could
    theoretically compromise all keys that have been negotiated using that
    certificate. In the worst case, this could be active NTS keys belonging
    to thousands (or more!) of clients.

I'm not able to oversee the implications of this requirement. 

    
    * NTS implementations could be vulnerable to "NTS stripping" attacks,
    where an attacker fools clients into reverting to plain NTP. Section 9
    should contain guidance on this. A naive NTS implementation might try to
    connect to the NTS-KE port at the NTP server's address and simply revert
    to plain NTP upon handshake or connection failure. This would be easy
    for a MITM attacker to exploit. Having the user explicitly mark a server
    as NTS compatible is an obvious mitigation. Another would be to forbid
    clients from performing unprotected NTP time synchronization with a
    server it has successfully performed NTS-protected synchronization with,
    at least for a certain amount of time (cf. HSTS).
    
    A more sophisticated attack would be a MITM attacker sending
    kiss-o'-death packets to the client, forcing it to reperform the NTS-KE
    handshake in a way that fails. It is important that clients do not
    revert to plain NTP here, but instead follow the draft: "As long as the
    NTS-KE handshake has not succeeded, the client SHOULD continue polling
    the NTP server using the cookies and parameters it has." This could also
    be used by an attacker with a forged or stolen certificate to force a
    NTS key renegotiation using that certificate.

This seems to be sound to me. Do you have an proposal to add this to Sec. 9? 
    
    * In reference to the previous point, we should consider public key
    pinning as a way for servers to protect against MITM attacks with forged
    certificates. The equivalent for HTTPS (HPKP) is specified by RFC 7469.
    This would require adding new record types to the NTS-KE protocol.

At this stage I wouldn't recommend to add a new record type to the protocol. 
    
    The argument against key pinning in NTS is that very few NTP server
    administrators are likely to want or need this feature and that this
    does not warrant further protocol complexity. Public key pinning is also
    a double edged sword in that administrator mistakes can cause long-term
    service unavailability for large numbers of users. This has happened on
    so many occasions that HPKP has been deprecated in the Google Chrome
    browser. (Google still pins their own certificates in Chrome though.)
    
    * The canonical way of configuring NTS is for the user to explicitly set
    the address of an NTS-KE server in his or her client. I believe this is
    a good idea in general. However, there is currently no way for someone
    who is using a NTP server to find out if it supports NTS or the address
    of its NTS-KE server. It is obviously possible to try to perform a
    NTS-KE handshake with the same address as the NTP server, but this will
    only work in cases where the NTP and NTS-KE servers share an IP address.
    My suggestion for this is that we use DNS SRV records to enable clients
    to find the NTS-KE server associated with a certain NTP server. The
    record for ntp.example.com would look something like this:
    _ntske._tcp.ntp.example.com. 86400 IN SRV 10 10 [[TBD1]] nts.example.com.
    where [[TBD1]] should be replaced with the port number assigned for
    NTS-KE. SRV records will also enable transition to NTS without any user
    interaction when support for NTS is implemented in NTP clients.


    
    * In Section 5.7, the paragraphs
    
    "To protect the client's privacy, the same cookie SHOULD NOT be included
    in multiple requests.  If the client does not have any cookies that it
    has not already sent, it SHOULD initiate a re-run the NTS-KE protocol."
    
    and
    
    "The client MAY reuse cookies in order to prioritize resilience over
    unlinkability.  Which of the two that should be prioritized in any
    particular case is dependent on the application and the user's
    preference.  Section 10.1 describes the privacy considerations of this
    in further detail."
    
    should be moved together for obvious reasons. Currently, one is in the
    beginning of the section and the other at the end.

I would leave the first paragraph as it is because this is important for the time_request message. The second paragraph provides a choice for the client (which may be moved to the Security Considerations) which I wouldn't move at the beginning of 5.7. But to have both of these statements grouped together we could change the beginning of the second paragraph to something like "Although the client should not reuse a cookie it MAY reuse it in  order ...". 

    
    * Missing word in the abstract: The sentence that begins with "The
    second handles encryption and authentication during NTP time via
    extension [...]" should be "The second handles encryption and
    authentication during NTP time synchronization via extension [...]".

Thanks for that. I updated the abstract at the github repro.
    
    Kind regards,
    Marcus Dansarie
    
    [1] Malhotra, Aanchal, et al. "Attacking the Network Time Protocol."
    NDSS. 2016. <https://ia.cr/2015/1020>
    
    _______________________________________________
    ntp mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/ntp