Spectrum of Echo uses

[chrysn]

Closes: https://github.com/core-wg/echo-request-tag/issues/74

---

While the first commit is close to the text I'd pick here (and ready to be vetted), some points are still open:

• [x] It's talking about "protecting the Echo value", where what I mean is "use an Echo value the client can't forge" (which can be either long random, MACed, AEAD'd and there's probably other equivalent options). Gotta find a better wording there.
• [x] Allowing the "for some applications" part may need some explaining (but I'd rather talk about it in the document than have implementers take the step on their own anyway).
• [ ] This probably needs alignment in other parts, especially where we talk about whether it MUST be identifiable etc., in the appendix examples, and possibly in other places. (I'd rather start that after a first round of review from you).

[edit: and yeah, I didn't run this through a final reading yet after forming the underlying ideas as I was writing, so there may be some unclosed parens or odd sentences left; sorry for those, hope the sentiment is clear still].

[chrysn]

Updated now to align further parts of the document, requesting preliminary review.

An open discussion point is that by the careful wording around source-of-truth, for the short Echo values we're not really claiming "freshness" (kind of leaving the term "freshness" for where the server can provably-even-with-a-malicious-client know that it is newer-than). I think it's generally fine to use the strong sense of freshness, but that means that we illustrate in echo-figure-event does not deserve the term "freshness". Options are:

• Keep the figure (with the short Echo values) and alter its description. This would be easiest if we introduce a term like "weak freshness" (better suggestions pretty please!) for "freshness but only as claimed by the client not as provable by the server", then the changes to the example/figure would be easy (and the wording in appendix A item 3 would be less clumsy).
• Add a MAC to the figure. This would be consistent with the "when you use unprotected Echo values you better damn well know what you're doing" sentiment of the rest of the text, but leaves us with no illustrated example of a short Echo.

Suggestions? I'm undecided between them, and would prefer not to toss a coin.

[chrysn]

(Ticking off the "protected Echo" box now because the security considerations line "Echo values without the protection of randomness or a MAC" reads reasonably well; if there's clarification needed left we can find that during review).

[chrysn]

Ping @gselander and @emanjon; I could really need a bit of feedback there.

[chrysn]

I'm merging this now to allow taking the final editing steps, but still would like to have another pair of eyes here -- but worst case that can happen after a submission tomorrow at cut-off date, and if the need for changes does come up, we work that into the P2P responses and let the reviewers know that a follow-up will come when the cut-off is over.