Subject: [Last-Call] Iotdir telechat review of draft-ietf-core-echo-request-tag-12

From: Eliot Lear via Datatracker <[email-masked]>
Date: Fri, 05 Feb 2021 09:09:49 -0800

Reviewer: Eliot Lear
Review result: Ready with Issues

All in all, a very nice piece of work.  I'm not reviewing for other than IoT
issues.

An issue in Section 2.2.1 (you decide if it's minor or major or really just a
question):

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.

Nit:

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.

---

From: Christian M. Amsüss <[email-masked]>
Date: Fri, 5 Feb 2021 18:52:48 +0100

Hello Eliot,

> 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).

> DTLS?  I found the inner/outer text confusing, and that a diagram might

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

---

From: Eliot Lear <[email-masked]>
Date: Fri, 5 Feb 2021 19:53:17 +0100

Christian,

Thanks.  This answers my questions well.

Regards,

Eliot

> On 5 Feb 2021, at 18:52, Christian M. Amsüss <[email-masked]> wrote:
> 
> Hello Eliot,
>