Hello Eliot,
On Fri, Feb 05, 2021 at 09:09:49AM -0800, Eliot Lear via Datatracker wrote:
> I do not understand why the Echo option requires opaque data, and why this
> should not be standardized, as it seems that the behavior you are seeking is
> standardized. As you give two example methods in the draft, why not reserve a
> few extra bits to specify which method is in use? This would also allow you to
> drop the necessary callback routines in libraries.
I don't see which callback routines would be involved here. In current
implementations, the value is passed around as an opaque buffer to the
component that is taking responsibility of the Echo option. If multiple
components inside the server produce Echo values and need to tell them
apart, the server is of course free to use the few bits as it needs
them (a pattern that's also used with similar opaque values like the
tokens). But maybe I did not quite get the point about the callbacks,
could you elaborate?
The behavior we are seeking and standardizing is the client's; servers
can use the option as a tool for a variety of applications (those in
section 2.4 and more) which can all work using the same generic client
behavior.
None of the envisioned applications have any data in there that'd be
relevant to the client, and worse, if the client were to understand it,
it could try to construct values, and all of a sudden the security
considerations for applications of this, like server state recovery,
would grow *way* more complex: From a simple rule ("Only send an Echo
value if you ever received it from that peer before") that the server
can rely on the client to obey, it'd grow into requiring the client to
understand when it may or may not tamper with the value.
If a particular application needs the client to understand a value of an
Echo-like value, it should take "the few bits" out of the option number.
(For example, I'd be happy to review a draft on sending a realtime
timestamp in requests -- but that would cover quite a different set of
use cases, and need vastly different security considerations).
> The last sentence in 2.2: is this meant to be limited to OSCORE or all uses of
> DTLS? I found the inner/outer text confusing, and that a diagram might
> actually help.
That sentence is merely illustrating the corner case exception, I'm
confident we can enhance readability here a bit by not referring to
DTLS. (It is general to DTLS in that in DTLS all proxies always see the
CoAP options; it says something about OSCORE is that (DTLS or not),
proxies see the outer options only).
On the general inner/outer diagram ... hm, we could add something
for sure, but I'd be worried that it'd distract by putting focus on a
topic that really belongs to OSCORE. I'll leave an issue open in the
authors' tracker to revisit this when more reviews have come in.
Thank you for your input
Christian
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
