Christian,
Thanks. This answers my questions well.
Regards,
Eliot
> On 5 Feb 2021, at 18:52, Christian M. Amsüss <christian@xxxxxxxxxxx> wrote:
>
> 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: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
