Re: [core] I-D Action: draft-ietf-core-echo-request-tag-13.txt

[Christian Amsüss <[e-mail]>]

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