Re: [Ntp] WGLC comments on draft-ietf-ntp-using-nts-for-ntp-14
Dieter Sibold <dsibold.ietf@gmail.com> Thu, 22 November 2018 16:51 UTC
Return-Path: <dsibold.ietf@gmail.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631C5130DE8 for <ntp@ietfa.amsl.com>; Thu, 22 Nov 2018 08:51:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0KiyZKAasIW for <ntp@ietfa.amsl.com>; Thu, 22 Nov 2018 08:51:54 -0800 (PST)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27BCE130DBE for <ntp@ietf.org>; Thu, 22 Nov 2018 08:51:54 -0800 (PST)
Received: by mail-ed1-x52b.google.com with SMTP id r27so8255886eda.0 for <ntp@ietf.org>; Thu, 22 Nov 2018 08:51:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=elSCl9v9rEU32os2Hic+y0l6bvywq/n4mlko9CsPXgo=; b=OAmfM5w5LePnoYXesrVhYQYndIFkrqXHvfLcN34wZccCS/G8uebsi1sUwIZ96cu+3+ UcP1kOgRXmk5QEBR2C//oNSOgpoEPqlcLCgjQhUnPG0MKokGKVoO5uJ0BZVvu0xRDdkN Q/seROv4/WiCK1RBCtTDfkgf/A6Eb/wzssxsoxyC3NWj8LoA5INu0nGodABNRCGVahZB oJ700veknyBPB4xyFxAJp/VZrp9A/Zi97rheAQcv2stRNoUOzIEpxqPWxsT9Yys/LVvw eJb/90C76+FJJ6kuStbxYhiOOw6Vtebby/6JIS1RfHRmlWbiyOq9YSn5byh+a6/5pAAr F83w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=elSCl9v9rEU32os2Hic+y0l6bvywq/n4mlko9CsPXgo=; b=IKWu94nA/KJRJ+g2X9F4AEYBR8wBN+mfsBp8+OsDD4DFnfVmF5k3lpcH22ArMvr4LO geQ2j5cy9TrgjkvZWGr19EE0TvL3/NKGgF89bo2bGKIo4Z3oCow8/Ik4eHTixm9B0nUL XPX1mx1ppVzpdp10JScm810zockK5zpLxJqklPXyJ+e9ZEuw2w7N8zXOusmPA85y6fQM JZmybF0JVc+huO5+6I1z0FpBbo8Q2+rBvvdwGN6cyfx6rwgTi9duosODPf87y6j1Hjib F+NlGkjNP7OebvnykcC7b/EbBRp0t68JG9bX41IgUNsx7LG/tVKZZsrfE+wp1EQsiSg/ IXEw==
X-Gm-Message-State: AGRZ1gJgqrlm+AuzDPRn92uXndm1PXhxbCuU60u2t0JvFXnA+VVJktE4 btnsN2QOQShETYTc2E4+tzZm93er
X-Google-Smtp-Source: AJdET5dysenX5ASiGtL5eu5v69c2aauv/lVWY3UAl7bie555AvPpaLe1NMaQJ/0J36ZRqnuRM5RJgQ==
X-Received: by 2002:a17:906:914:: with SMTP id i20-v6mr8648226ejd.225.1542905512337; Thu, 22 Nov 2018 08:51:52 -0800 (PST)
Received: from AM4PR0801MB2738.eurprd08.prod.outlook.com ([40.101.16.141]) by smtp.gmail.com with ESMTPSA id b2sm5264692ede.30.2018.11.22.08.51.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Nov 2018 08:51:51 -0800 (PST)
From: Dieter Sibold <dsibold.ietf@gmail.com>
To: Marcus Dansarie <marcus@dansarie.se>, "ntp@ietf.org" <ntp@ietf.org>
Thread-Topic: [Ntp] WGLC comments on draft-ietf-ntp-using-nts-for-ntp-14
Thread-Index: AWJlYTQ0htQHDVjA/v0Utp3jnRLFl2ViODIz4Q8zKPo=
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Thu, 22 Nov 2018 16:51:50 +0000
Message-ID: <AM4PR0801MB2738A77F79B507E58F57ABC8F8DB0@AM4PR0801MB2738.eurprd08.prod.outlook.com>
References: <db984964-799a-4c06-ceaa-ca96e9ba5d3b@dansarie.se> <fdf553a3-ae9a-2eeb-248a-2fccbde6f33e@dansarie.se>
In-Reply-To: <fdf553a3-ae9a-2eeb-248a-2fccbde6f33e@dansarie.se>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/NYCPrS77qhPevjVLSYsMQEd9jBE>
Subject: Re: [Ntp] WGLC comments on draft-ietf-ntp-using-nts-for-ntp-14
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Nov 2018 16:51:57 -0000
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" <ntp-bounces@ietf.org im Auftrag von marcus@dansarie.se>: 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 ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp
- [Ntp] WGLC comments on draft-ietf-ntp-using-nts-f… Marcus Dansarie
- Re: [Ntp] WGLC comments on draft-ietf-ntp-using-n… Dieter Sibold
- Re: [Ntp] WGLC comments on draft-ietf-ntp-using-n… Marcus Dansarie
- Re: [Ntp] WGLC comments on draft-ietf-ntp-using-n… Marcus Dansarie
- Re: [Ntp] WGLC comments on draft-ietf-ntp-using-n… Dieter Sibold
- Re: [Ntp] WGLC comments on draft-ietf-ntp-using-n… Dieter Sibold
- Re: [Ntp] WGLC comments on draft-ietf-ntp-using-n… kristof.teichel
- Re: [Ntp] WGLC comments on draft-ietf-ntp-using-n… kristof.teichel
- Re: [Ntp] WGLC comments on draft-ietf-ntp-using-n… Marcus Dansarie