[core] Chair's review of draft-ietf-core-echo-request-tag-03.txt
Carsten Bormann <cabo@tzi.org> Wed, 06 February 2019 14:58 UTC
Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C85124BF6; Wed, 6 Feb 2019 06:58:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
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 ns6nLQMXJ6Yu; Wed, 6 Feb 2019 06:58:15 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19564126BED; Wed, 6 Feb 2019 06:58:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x16Ew3Ku021273; Wed, 6 Feb 2019 15:58:08 +0100 (CET)
Received: from [192.168.217.106] (p54A6CC50.dip0.t-ipconnect.de [84.166.204.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 43vl1R1RVNz1Br6; Wed, 6 Feb 2019 15:58:03 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
Date: Wed, 06 Feb 2019 15:58:02 +0100
Cc: draft-ietf-core-echo-request-tag@ietf.org
X-Mao-Original-Outgoing-Id: 571157880.431689-ba9f5cfd41283b7f4d7f7f7e72d2ab7f
Content-Transfer-Encoding: quoted-printable
Message-Id: <963CE8EA-ABAC-488A-8FA6-81431A2E5B06@tzi.org>
To: "core@ietf.org WG" <core@ietf.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/aLdE98xyPJGc-ERiKc9DDNagWKI>
Subject: [core] Chair's review of draft-ietf-core-echo-request-tag-03.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Feb 2019 14:58:17 -0000
In preparation for the impending working-group last call, I have reviewed draft-ietf-core-echo-request-tag-03.txt. Substantive comments are below; a set of small editorial comments is going to the authors in parallel. Grüße, Carsten # Major Completely outlawing token reuse is throwing out the baby with the bathwater -- requiring stable storage for token numbers even in situations where that is not needed. (Of course, if you have that, keeping a token counter e.g. per DTLS connection is a great implementation strategy.) Instead, the recommendations about Token reuse should be specific to the cases covered. This does require some additional work. (The actual wording in Section 5 is closer to reason, but the introductory material gives a different impression.) The wording in Section 5 needs to be clarified that this is a requirement on clients, not a license to servers to base their operations on the assumption that this requirement is always fulfilled by a client -- the token processing rules of RFC 7252 still apply. # Minor * The document fails to mention that the "echo" function can also be provided at the application layer, e.g., with freshness tokens in "forms", as they are widely used with HTTP. It should make clearer that "Echo" is just a convention to provide these freshness tokens, in particular when there is no natural way to keep the freshness tokens in the application data. * Is "operation" the term we want to use henceforth? * The "MUST NOT process" in 2.2 is weird, as it is qualified by the undetermined "has freshness requirements". Maybe the text should focus on the concept of "fresh enough", which would also explain the license for the client to re-use Echo values in further requests. The time-based processing model ("RTT < T") is one way to handle "fresh enough", but certainly not a MUST -- there are event-based freshness models. * 2.2: Clarify "The CoAP client side of HTTP-to-CoAP proxies SHOULD respond to Echo challenges themselves" * 2.3 item 2 (time and state sync) is very opaque; its statements have not been analyzed in this review. * Section 3 is confused about Request-Tag Options and lists of those. Why was the option marked repeatable? Or, what is wrong with a non-repeatable Request-Tag Option that defaults to the empty string (as opposed to a repeatable one that by definition defaults to the empty array/"list")? * Section 6 (Security Considerations) MUST NOT use BCP14 language. Move the mandates up to where they belong. "Is not allowed" about implementation strategies also is weird requirements language (in particular when the prohibition is just a result on some other implementation choices that aren't really required). * Requiring a monotonic clock is a consequence of the implementation model proposed (time-based freshness) and is not needed with other forms of freshness. In any case, if the non-monotonisms are limited to below the freshness requirements (as they would be for most usages of civil time), the are inconsequential, so these security considerations require some qualification even when phrased as such. Monotonic vs. wall-clock is somewhat orthogonal to non-hackable vs. hackable, anyway. * Appendix A could contain some help with the selection of n. # Editorial * Title and Abstract. The title probably should mention CoAP. The abstract might want to say what the introduction already says: This is for supporting specific use cases (i.e., not all use cases will need these additions). * Introduction. The introduction could say earlier that Request-Tag is intended exclusively for combination with Block1 options. * Section 2 would benefit from discussing freshness as a concept first, and then introducing the Echo Option as one convention to achieve the objectives. In particular it should be clear that the rendition of Echo with a 4.01 may be an unusual case in many applications. * Section 3 would benefit from explaining that Request-Tag is only meant to be used with Block1 Options in requests.
- [core] Chair's review of draft-ietf-core-echo-req… Carsten Bormann
- Re: [core] Chair's review of draft-ietf-core-echo… Christian M. Amsüss
- Re: [core] Chair's review of draft-ietf-core-echo… John Mattsson
- Re: [core] Chair's review of draft-ietf-core-echo… Christian Amsüss