[Ntp] Danny's Review (was Re: draft-ietf-ntp-roughtime-05: tag change makes implementation more complex)

Watson Ladd <watsonbladd@gmail.com> Tue, 28 September 2021 01:48 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 384E93A0FD4 for <ntp@ietfa.amsl.com>; Mon, 27 Sep 2021 18:48:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id lWuOYmEpzHcQ for <ntp@ietfa.amsl.com>; Mon, 27 Sep 2021 18:48:52 -0700 (PDT)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 5310B3A0FC6 for <ntp@ietf.org>; Mon, 27 Sep 2021 18:48:52 -0700 (PDT)
Received: by mail-ed1-x531.google.com with SMTP id s17so58197512edd.8 for <ntp@ietf.org>; Mon, 27 Sep 2021 18:48:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ECBIMYeef/QK4C+dJFJLsATPkSGPN2kwDpYerg2n0Io=; b=E+Eos+CnbrBfakPdq3kNgSi2xuu2mFnOnwXc0vWJ/Cc6b8S2pSqN/6WTGN/F7xuV+A YJqHvRjX6CxKshROasNxqt2qDzAygQWox5UvSBQUemjkzLl4jvhtAkoUn8fz+f5iU7dc 2DA6YFoJtNm6izx20uJ9FIG1evq4pp5Bq6V+wHTkAhdrPVqPfcz/BrSQlSWMLUFxHrmI pS2mxmxR1C/h5MQpYHfCb1xL70iq7wvdgRdYFcHWBm1bmm1KofiXsU51u5FnydRVb7i0 skNwsMqYKhx+DUCNUfZltWHv3ILW+M9PiFBjG40Kh78vjgtqYi4dQWWKVVG2zrGKQKk1 F3qw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ECBIMYeef/QK4C+dJFJLsATPkSGPN2kwDpYerg2n0Io=; b=QKByA5dmLzKLr9Bty2NjfE2jIYwnyKZGjtPZwtsQj7oHJd1v9h7QCdm0aRsTrWQC3P X/BCxaSKEWJeRKCPfEnN5zZTl63JuG0bABQfCa/cv/PPRUJIa509NuWQvALFq8+B1qpZ ADU63owdOzYs9Ju1uRXGZVIBDxCtRD98Qz0uPCGOq1hCEXfJ1CU7lNo5S6EHNESiKMbH B0n5kxUeqD8qHrgKeDiqjO7kVQgpZzWfCwvo3IqpxHb+6nXgZd5usmXiHzQfR1LMN2bX z0qy9UnI0R/pYQgIeXEDiTWYl+S2OAbKgRnj922wLT4gme7n5qNVW7/HU1v01N2AG2gV aL0Q==
X-Gm-Message-State: AOAM530XdzOKd/Vz/Rj3j1li79tSloy246PslArzy+UovLq1mCtHtZbL IRjYXXKhQNPZkAe7ECFka3GqQNHkjtdnHhBxh5g=
X-Google-Smtp-Source: ABdhPJx2vnN/jYWbJZqlozNwwiV9q0K+ZO7O+yzcQ80iub8M0CfZx9Npp/wLQxeKJa0zgHNlqfZDz+Hibogz6Clawko=
X-Received: by 2002:a17:906:7d42:: with SMTP id l2mr3947112ejp.467.1632793728567; Mon, 27 Sep 2021 18:48:48 -0700 (PDT)
MIME-Version: 1.0
References: <CAGZkp1-ZCuSvMyQyWCnE511O8-WL=OXfsTdraKsByMmWC3spVA@mail.gmail.com> <CACsn0ckZmR=k2NAmdyhVOA=V_XQ18AnBUBSTOu+bDXS1YsPpUg@mail.gmail.com> <CAGZkp18eASaF7qvubYpDgzvg643ZXuPwDs9qsiC1P_AVLcywLA@mail.gmail.com> <CACsn0cnjHFwxHT13nMavRFzRteWJ=SORY8v4RCZjdjYP0H3oaw@mail.gmail.com> <7dde7eb3-4dc7-94d3-e63a-6d5d0736b1c2@pdmconsulting.net> <54baf1fa-b138-4eb8-6f4e-99168cf2db7b@dansarie.se> <0a95d35f-f708-4a3c-4ecf-77597c42a7a4@pdmconsulting.net> <CACsn0c=gdQWDumfzeHYYWzXPV4sz4J9mTUtYW+4=KueaHHbGdQ@mail.gmail.com> <79dfd56c-54e8-8b85-ed9d-da9fac71d1f1@pdmconsulting.net> <c95eaafb-f294-a54e-d495-0cf74e574686@pdmconsulting.net>
In-Reply-To: <c95eaafb-f294-a54e-d495-0cf74e574686@pdmconsulting.net>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Mon, 27 Sep 2021 18:48:37 -0700
Message-ID: <CACsn0cmks2fdwem1rS+QNzCL1WhNR4890Fi1zpjQrL=E3Y=3fQ@mail.gmail.com>
To: Danny Mayer <mayer@pdmconsulting.net>
Cc: Marcus Dansarie <marcus@dansarie.se>, NTP WG <ntp@ietf.org>, JP Sugarbroad <taralx@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/ECO2SxGuFY6J4walL0sU8f2zvSU>
Subject: [Ntp] Danny's Review (was Re: draft-ietf-ntp-roughtime-05: tag change makes implementation more complex)
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <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: Tue, 28 Sep 2021 01:48:58 -0000

On Mon, Sep 27, 2021 at 9:31 AM Danny Mayer <mayer@pdmconsulting.net> wrote:
> I have been reviewing the draft again and it's not ready for
> publication. Here are a number of additional issues.

Thanks for your review! We shall revise soon.
> 1. Section 6: "Servers SHOULD support the UDP transport mode, while TCP
> transport is OPTIONAL."
> Unless you specify some other transport one of these needs to be
> mandatory. "SHOULD" is probably a "MUST". There is no explanation about
> why TCP might be used instead of UDP, so that needs clarification. If
> there is a good reason to be sending multiple requests and responses
> over TCP, please explain why this is preferable.

We can add explanatory text: TCP is for supporting Tor. I think making
UDP a MUST works, although chances are not every server will
necessarily have as good reachability over UDP.

> 2. The message format (Figure 1) seems bizarre. Number of pairs
> The number of pairs shouldn't need 32 bits, I suspect that 16-bits is
> more than enough. You can use the rest of the 16 bits for something
> else, like version information.

We want to minimize the number of numeric types. There's plenty of
room for a version number in its own tag which we do.

> 3. The message format (Figure 1). You seem to have tag identifiers after
> offsets and then values. Why not have the tag followed by a length of
> the value followed by the label? Why are you going to all the trouble of
> using offsets? Even if you are going to use offsets why isn't the tag
> identifier before the offset or even a tag identifier with the offset?
> The offsets don't need to be 32-bits in size, 16-bits is more than
> enough unless you are intending to send megabytes of packets. Note that
> is seems to be assumed that the offsets are in exactly the same order as
> the tag identifier specified separately. That's a bad assumption to
> make. It's not clear why the offsets have to be in strict ascending
> order, it shouldn't matter as long as you can correlate it to the tag
> identifier.

Nested TLV protocols are a major source of vulnerablities and
surprises. By having the tags always sorted the same way, and the
offsets in ascending order, we ensure that the data of different
sections is nonoverlapping and that identical tag->data maps have
identical representations. The 4 byte alignment is sometimes
convenient: we're not hurting for space here.

> 4. TAG values
> Here's another problem. Consider this from section 6.1.1: "the VER tag
> contains a list of versions". Actually the tag appears to be just a tag.
> If I interpreted the format from Figure 1 correctly, the TAG identifier
> is separate from the values and in this case the list of versions. None
> of the TAGs specified in section 6 specify the format of these values
> and what the list in the case of VER would look like. The length of
> these values are not specified anywhere except in the offset section
> which has to then interpret how long the value is which may or may not
> be a multiple of 4 bytes.

Perhaps contains is not the right verb. We mean that the value
associated to the tag is the list of versions. All values are
multiples of 4 bytes. The message formats delinates the length of all

> 5. VER values
> That is the meaning of the version? What does the version depend on? Is
> this the version of the protocol? Of the message? Of something else?

Of the protocol. This will be clarified.
> 6. Secton 6.2.5 SREP
> This is totally unclear. If references other tags: ROOT, MIDP, RADI,
> DUT1, DTAI, LEAP, but they seem to be part of the SREP values rather
> then part of the overall message. Are they a separate set of tags or do
> they only appear under SREP and if only under SREP then how is SREP
> formatted.

SREP is formated as Roughtime message. That is the tags and their
associated values are serialized in the same offset tag data format.
The rest of the paragraphs in this section define each of these

> 7. INDX tag
> It's unclear what the need for this tag is. Section 6.2.7 says that it
> identifies the postion of the NONC but since the NONC is already in the
> message this seems to be a duplicate. The reference to the Merkle tree
> doesn't clarify this at all. Confusingly then Section 6.3.1 goes on to
> say: "The bits of INDX are ordered from least to most significant in
> this algorithm" which seems to be unrelated to the NONC.

The NONC is inserted into a Merkel tree that contains the NONC of
other messages. This is then signed. INDX indicates where in the
Merkel tree NONC is. We will add text to clarify this.

> 8. CERT
> The contents seem to include other tags. It's not clear why these, like
> the ones mentioned in SREP are not separately specified.
> 9. Hashing algorithm in Section 6.3
> It's not clear why the algorithm can only be SHA-512. This really should
> be separately referenced so that if SHA-512 is considered too week in
> can be replaced by a different hashing algorithm like say HMAC-SHA-512,
> without having to update the proposed RFC.

Part of what is required for roughtime is interoperability between all
servers, auditors, and clients. Using only a single hash function and
signature, and then migrating entire versions, is a better approach
than permitting everything.

> 10. Grease (Section 8)
> This seems to be garbled: "Servers MUST NOT send back responses with
> incorrect times and valid signatures.  Either signature MAY be invalid
> for this application." What does that even mean?

We mean that servers may send back invalid signatures. This text will
be clarified.

> 10. Examples of each and every tag and value would be helpful. It's hard
> to understand what each tag is providing and how the values are
> formatted and interpreted.

We shall add test vectors.

> This is enough for now.

Thank you for your detailed comments.

> Danny

Astra mortemque praestare gradatim