Re: [core] I-D Action: draft-ietf-core-echo-request-tag-13.txt
Christian Amsüss <christian@amsuess.com> Sun, 18 July 2021 20:18 UTC
Return-Path: <christian@amsuess.com>
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 7AEB23A08E6; Sun, 18 Jul 2021 13:18:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.101
X-Spam-Level: ***
X-Spam-Status: No, score=3.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 GUREeT0cXhiO; Sun, 18 Jul 2021 13:18:24 -0700 (PDT)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6969C3A08E4; Sun, 18 Jul 2021 13:18:24 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 87BF94010C; Sun, 18 Jul 2021 22:18:21 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 61242D0; Sun, 18 Jul 2021 22:18:20 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [188.20.219.122]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 0784D148; Sun, 18 Jul 2021 22:18:19 +0200 (CEST)
Received: (nullmailer pid 2667521 invoked by uid 1000); Sun, 18 Jul 2021 20:18:19 -0000
Date: Sun, 18 Jul 2021 22:18:19 +0200
From: Christian Amsüss <christian@amsuess.com>
To: core@ietf.org, draft-ietf-core-echo-request-tag.all@ietf.org
Message-ID: <YPSMi3o6gWvk9PEt@hephaistos.amsuess.com>
References: <162613081317.26331.17084230218140543874@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="ASfgTvVcotsh3GMW"
Content-Disposition: inline
In-Reply-To: <162613081317.26331.17084230218140543874@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/SIHjiM5AjFRZJRZGUjf3cW1sUu4>
Subject: Re: [core] I-D Action: draft-ietf-core-echo-request-tag-13.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: Sun, 18 Jul 2021 20:18:30 -0000
Hello CoRE and all involved in "CoAP: Echo, Request-Tag, and Token Processing", with the submitted -13 version, Göran, John and I think that all pending comments are addressed, and that the document should be ready to proceed. Thanks to all who provided comments, they were useful throughout and helped improve the document. We've found a few issues even with the published document (one of them being that I neglected to express the above sentiment in the acknowledgements section; another that the title may need some work to make a useful abbreviation, the rest editorial trivialities) -- however, we are confident that they are fixable in parallel to further processing at the RFC editor. In addition to the diffs available in the usual locations[1], there is now full list of changes between versions 12 and 13 at the end of the mail. (The list was just not ready in time for the cut-off...). Point to point responses are being sent to the latest round of reviewers and all reference this mail for introductions. As several points culminated in the addition of the new "Characterization of Echo Applications", a common answer referred to by the label GENERIC-SHORT-ECHO is provided at the end of this mail. Hoping that this at last ends the five and half years of MISSREF in C280 Christian [1]: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-echo-request-tag-13 ## GENERIC-SHORT-ECHO The explanations as to the required properties of Echo values were inconsistent: Section 2.3 "Echo Processing" required that the server MUST be able to verify that the Echo value is genuine, but at the same time the permitted minimal length and the example in Appendix A item 3 indicated that this would not always be the case. In parallel, Ben Kaduk's review asked for elaboration on the spectrum of requirements -- of which some extremes call for verifiable Echo values, and others not. Consequently, a section "Characterization of Echo Applications" was added that discusses three aspects: "authority over synchronized property", "Time vs. Events" and "applicable security protocools". In the former, we derive when using guessable Echo values is OK, and when not. In the remaining texts, the ambiguous points were clarified (often pointing at the new distinctions). In particular, the security considerations used to conflate the topic of "authority over synchronized property" with the Counter implementation -- while these generally do coincide, the new text is more precise and refers back to the new section. ## Change log from -12 to -13 * Add subsection "Characterization of Echo Applications". * Changes in applications and appendices to use the newly introduced terms. * In particular, some of the legitimization for using short Echo values was drawn from the applications being event based; the concept of the client being the "Authority over [the] Used Information" now legitimizes these more precisely. * Add subsection "Updated Amplification Mitigation Requirements for Servers". It contains the normative text updating RFC 7252 w/rt recommended mitigation methods, which previously happened in passing. * Amplification mitigation: * Increase precision: Reachability check is performed once per endpoint (was: peer). * State that amplification factor applies to the sum of all (previously: "the size of the", implicitly, single) returned packets. * Fix odd wording around how the Echo value would "contain" the claimed address: was meant to contain in a cryptographic sense, now clarified in that a MAC is recommended * Define "preemptive Echo value" that was previously used without definition; another occurrence of the concept was simplified using the term. * Add considerations for the use of DTLS without replay protection. * Privacy considerations: Address concerns raised in various numeric-ids documents. * Explicitly state expected security modes for Echo applications and examples. * Fix of requirements for H-C proxies: They *MUST NOT* relay unsafe requests. (Previously, it only said that they SHOULD use a particular method, but not clearly that some method is mandated.) * Clarify that state synchonization is an application of the freshness results in combination with some transported application data, and not an immediate result of using Echo alone. * Add text to tie together applications and suggested mechanisms * Restrict C-C proxy allowed behavior: Only safe requests (incorrectly said "idempotent") may be used to proactively populate the proxy's cache. * Justify some "SHOULD"s by outlining justification for different behavior. * Normatively require H-C proxies to process Echo if they're justified to do so, as no alternatives are available. * Reference updates: * QUIC is now RFC9000; precise section given as amplification reference. * Add note for RFC editor that RFC6347 can be upgraded to DTLS 1.3 if C321 overtakes C280 * Follow the core-coap-actuators to core-coap-attacks update * RFC8470 reference is now normative (as using what's defined there has been RECOMMENDED already) * Editorial fixes * Rewording of confusing sentences in amplification mitigation and inner-/outer Echo values * Replace "blacklist" terminology with "deny-list" where left after other changes * Removed sloppy use of Echo as a verb * Minor clarifications * Remove duplicate statements * Typography and spelling fixes * Fixes that are not editorial but minor * Freshness is about time, of which round-trip time (specialization now removed) is only a part. * Reference how HTTP *1.1* does it when explaining token requirements, as that's an easily and widely understood baseline. -- A beginning is the time for taking the most delicate care that the balances are correct. -- Princess Irulan, Manual of Muad'Dib
- [core] I-D Action: draft-ietf-core-echo-request-t… internet-drafts
- Re: [core] I-D Action: draft-ietf-core-echo-reque… Christian Amsüss