Re: [Iot-directorate] Iotdir telechat review of draft-ietf-core-echo-request-tag-12

["Eric Vyncke (evyncke)" <[e-mail]>]

Eliot: thank you for your review, I just repeated it in the 'no objection' IESG ballot for archiving purpose
Christian: thank you for your quick reply to Eliot's review

-éric


-----Original Message-----
From: Iot-directorate <[e-mail]> on behalf of Eliot Lear <lear=[e-mail]>
Date: Friday, 5 February 2021 at 19:53
To: "\"Christian M. Amsüss\"" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Iot-directorate] Iotdir telechat review of draft-ietf-core-echo-request-tag-12

    Christian,

    Thanks.  This answers my questions well.

    Regards,

    Eliot

    > On 5 Feb 2021, at 18:52, Christian M. Amsüss <[e-mail]> 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