Re: [Ntp] WGLC comments on draft-ietf-ntp-using-nts-for-ntp-14
Dieter Sibold <dsibold.ietf@gmail.com> Wed, 21 November 2018 21:18 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 EC86C130F1F for <ntp@ietfa.amsl.com>; Wed, 21 Nov 2018 13:18:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] 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 7gBRdBSHxY7m for <ntp@ietfa.amsl.com>; Wed, 21 Nov 2018 13:18:42 -0800 (PST)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 200BB130F2D for <ntp@ietf.org>; Wed, 21 Nov 2018 13:18:42 -0800 (PST)
Received: by mail-ed1-x534.google.com with SMTP id z28so6023076edi.8 for <ntp@ietf.org>; Wed, 21 Nov 2018 13:18:42 -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=A683HmBxeINfR2vUSmxp1HBSGtHBgx6y8FtGicvag4k=; b=syHmXauOXu19hnrdZQx3fCvfx2A4UPRhL4nvIjeMGm/idPebYLNuo82dRHUGCcshlX KUDi64qmYT2l/pR8AYxx05Z8Pa4lztiWLILdoY8Fs8cE6EPfpZp0f+Bri/Fsn8tdmdbi +Udx2NBVrtiIhklgcFBTAzOHH46tWot0x1q4R9mWc2sJDACcjtyykjgNItmTeaT15n7o GoxHy28IWk6cZ9lPxgyN336dBzX5bHD67gRzOxiHe585qDIilju1st74IDyH9NMiYxVh DNEkbXFnJZUb8oapr5OWUvHj/LRmB6KsLJDuCzK5NX91gjWmYe23vvJOIXjDaN9oXlZQ iCIw==
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=A683HmBxeINfR2vUSmxp1HBSGtHBgx6y8FtGicvag4k=; b=SxAZnBsxfpIgIlAdqwrRFmYJN0U0DvxRVGZe89ASLK4fG3waSwRJiWeuANnINYP4sB 0WuBTtrpqD/L5IaW3UHoFUKrAOAx34SyemcfFapNYApOaiTYVN/9PuD8FeFYtzXOmvq7 mbktheQMCu4V024zfVSjKnuYfvWT2MXxCi+Wkqrfu+wyXcbdvaZXNB2mRoH1KGOb9ci7 He1AAuodhNIPqGkBLcIIaRHQos/hjUAI0BKWeAFzfSIfrS/Q8fHk/ZapXLmp6Qqptzw/ rVIfQXZG7oX38W3aeJmMS5mLKvApBut+4MdFzJrTrWv9ZhSYzOoQYWBx2lQ9a8zpYfbJ x/wg==
X-Gm-Message-State: AA+aEWZ1Ql+cAmsi9wIb8EUW/uwSA7DNi/rRCbSw9q4NwE0y6QrNzvhs KgeR8RHAhG9OjBIcic52izA=
X-Google-Smtp-Source: AFSGD/VvXfp0fQGVKUFf4w50TTSyDP1TtIVuk5nVn1Rv8FI5nHs2Q3UZoX5wjKQb7lIVpqbiGID3Fw==
X-Received: by 2002:a50:8ad6:: with SMTP id k22mr6668061edk.189.1542835120499; Wed, 21 Nov 2018 13:18:40 -0800 (PST)
Received: from AM4PR0801MB2738.eurprd08.prod.outlook.com ([40.101.16.141]) by smtp.gmail.com with ESMTPSA id e54sm3321605edd.71.2018.11.21.13.18.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Nov 2018 13:18:39 -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/v0Utp3jnRLFl+Q4/R7v
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Wed, 21 Nov 2018 21:18:38 +0000
Message-ID: <AM4PR0801MB273811B9F833418FCA0CE3A6F8DA0@AM4PR0801MB2738.eurprd08.prod.outlook.com>
References: <db984964-799a-4c06-ceaa-ca96e9ba5d3b@dansarie.se>
In-Reply-To: <db984964-799a-4c06-ceaa-ca96e9ba5d3b@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/twg6XD9sn463uw2fijl_MOFKW6U>
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: Wed, 21 Nov 2018 21:18:55 -0000
Hi Marcus, sorry for the late response. See my comments inline. Am 15.11.18, 23:00 schrieb "ntp im Auftrag von Marcus Dansarie" <ntp-bounces@ietf.org im Auftrag von marcus@dansarie.se>: 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." The first sentence of your suggestions implies that the clients should fall back to standard unsecured NTP if there the NTS layer is faulty or attacked. Is that your intention? I support the second sentence (the word increased replaced by decrease). * 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. I wasn't in favor for this requirement. However, in the meantime RFC 8446 was released and implementations of TLS 1.3 are available now. I therefore agree with you and Ragnar. I would like to learn about Daniel's and Kristof's opinion. * 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." Agree. * 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. That is a good point. 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. I agree with this statement! Kind regards, Marcus Dansarie and Ragnar Sundblad _______________________________________________ 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