[core] AD review of draft-ietf-core-echo-request-tag-10

[Barry Leiba <[e-mail]>]

Thanks for the work on this document.  I have a number of comments about
things that I think need clarification or rewording in my review below, so
I’m setting the state on the document to “revised I-D needed.”  Please ask
if you have questions or disagreements with anything below, and let’s
discuss anything that needs discussion.

I would prefer it if the document were specific about what “when CoAP is
used with security” means, ideally not using that phrase at all, as
“security” without explanation isn’t meaningful.  If you mean “over an
encrypted channel”, please say that.  Or something else?

— Section 1.1 —

   Unless otherwise specified, the terms "client" and "server" refers to

Nit: “refer to”, plural.

   The complete interchange of a request and a response body is called a
   (REST) "operation".

“REST” will need expansion and a reference.  You can copy these from 7252.

   Two request messages are said to be "matchable" if they occur between
   the same endpoint pair, have the same code and the same set of
   options except for elective NoCacheKey options and options involved
   in block-wise transfer (Block1, Block2 and Request-Tag).

There’s something missing here: this says, “X is true if A, B.”  It needs
an “and” or an “or” instead of the comma, no?

   Two matchable block-wise operations are said to be "concurrent" if a
   block of the second request is exchanged even though the client still
   intends to exchange further blocks in the first operation.

This appears to describe concurrent block-wise request operations.  Can
there also be concurrent block-wise response operations?

— Section 2.2 —

   but also in general for synchronizing state between CoAP
   client and server, cryptographically verify the aliveness of the
   client, or force a client to demonstrate reachability at its claimed

Nit: This isn’t parallel: the first item uses “synchronizing”, so the
second should use “verifying” and the third should use “forcing”.

— Section 2.3 —

   One way for the server to verify freshness is that to bind the Echo

Nit: There appears to be an extra word, “that”.

   (In most cases, this means that the proxy
   needs to ask the client to repeat the request with a new Echo value).

Nit: the “.” needs to be inside the parentheses.

— Section 3.3 —

   results in the new message not being part of he old operation.

Typo: “the old”

— Section 3.4 —

   What constitutes a concluded operation
   depends on that purpose, and is defined there.

I’m missing the antecedent to “there”.  Where?

   The Request-Tag options MAY be present in request messages that carry
   no Block option (for example, because a Request-Tag unaware proxy
   reassembled them), and MUST be ignored in those.

I think this should be “may” (or “might”), not “MAY”.  You’re not
suggesting it as an option to do, but are instead warning about something
that might happen.

— Section 3.5.1 —

   is still possible for a man-in-the-middle to maliciously replace a
   later operation's blocks with an earlier operation's blocks

Not a requirement here, and I will accept your best judgment:  in the
spirit of recent discussion on inclusive vs exclusionary language, I ask
you to consider changing “a man-in-the-middle” to “an on-path attacker”.

      changed, then the client MUST consider messages sent to _any_
      endpoint address within the new operation's security context.

This is ambiguous.  I think you mean “to be within”, yes?

   o  The client MUST NOT regard a block-wise request operation as
      concluded unless all of the messages the client previously sent in
      the operation have been confirmed by the message integrity
      protection mechanism, or are considered invalid by the server if
      replayed.

It’s not clear to me how a client can comply with this: how can the client
possibly know whether the messages it has sent would be considered invalid
by the server if they were replayed?  Or is there something I’m not
understanding?

Honestly, I’m having trouble following the explanations in this section, in
general, so there’s a reasonable chance that I am missing something.

— Section 3.6 —

   key, because to proxies unaware of the Request-Tag option

Nit: I think “to” is an extra word.

   The Request-Tag option is repeatable because this easily allows
   stateless proxies to "chain" their origin address.  They can perform
   the steps of Section 3.5.3 without the need to create an option value
   that is the concatenation of the received option and their own value,
   and can simply add a new Request-Tag option unconditionally.

I don’t know what ‘“chain” their origin address’ means, and I don’t know
what ‘their own value’ means.  Can you clarify this?

   In draft versions of this document, the Request-Tag option used to be
   critical and unsafe to forward.  That design was based on an
   erroneous understanding of which blocks could be composed according
   to [RFC7959].

It makes sense that this was here during working group discussion.  Is
there value in having it in the published RFC?  If so, why?

— Section 3.8 —

   The threat model here is not an
   attacker (because the response is made sure to belong to the current
   request by the security layer), but blocks in the client's cache.

I don’t understand “The threat model is blocks in the client’s cache.”  I
think this needs some rewording to explain better what you mean.

— Section 4.1 —

   The wrong response may be an old response for the same
   resource or for a completely different resource

Are you referring to an old response for a completely different resource
(which is what this says as written), or to any response for a completely
different resource (which is what I think you mean)?  If the latter, it
should say, “...or a response for a completely different resource”.

   A straightforward mitigation is to mandate clients to not reuse
   Tokens until the traffic keys have been replaced.  One easy way to
   accomplish this is to implement the Token as a counter starting at
   zero for each new or rekeyed secure connection.

This is essentially repeated in the next section.  Can you avoid that,
probably by rewording this to say that the next section privides a
mitigation?

— Section 4.2 —

   One easy way to accomplish this is to implement the Token (or part of
   the Token) as a sequence number starting at zero for each new or
   rekeyed secure connection, this approach SHOULD be followed.

This is not a proper sentence: I think it’s two sentences splicd together,
but it might be that it needs rewording instead.

— Section 5 —

   As each pseudoranom number must only be used once,
   an implementation need to get a new truly random seed after reboot,
   or continously store state in nonvolatile memory, see ([RFC8613],
   Appendix B.1.1) for issues and solution approaches for writing to
   nonvolatile memory.

Nit: “needs”, singular.

And this also looks like two sentences spliced together.

   Unless a counting Echo value is used, the Echo
   option value MUST contain 32 (pseudo-)random bits that are not
   predictable for any other party than the server, and SHOULD contain
   64 (pseudo-)random bits.

What’s the reason for not just using MUST for 64 bits and being done with
it?

   They MUST only be
   used when the request Echo values are integrity protected.

I think this is a tricky way to word it, and that it invites
misunderstanding.  I suggest that it might be better said as, “They MUST
NOT be used unless the request Echo values are integrity protected.”

   Servers MAY use the time since reboot measured in some unit of time.

For what?  It’s not clear to me what this refers to.

   the server MUST reject all Echo values that was created before

Nit: “were”, plural.

— Section 5.1 —

   Reusing Tokens in a way so that responses are guaranteed to not be
   associated with the wrong request is not trivial as on-path attackers
   may block, delay, and reorder messages, requests may be sent to
   several servers, and servers may process requests in any order and
   send many responses to the same request.

This is a complicated sentence and it has a lot of cascaded negatives.
Please try rewording it, and consider splitting it up.  One way is to start
with “On-path” to the end of the sentence, and then have another sentence
that says, “That makes it non-trivial to reuse tokens...”

      client is sending TLS protected requests without Observe

Nit: hyphenate “TLS-protected”.

— Section 6 —

   Implementations SHOULD NOT put any privacy sensitive information

Nit: hyphenate “privacy-sensitive”.

   Unencrypted timestamps MAY
   reveal information about the server

This needs to be “may” (or “could”), as it’s a statement, not a directive.

   Like HTTP cookies, the Echo option could potentially be abused as a
   tracking mechanism to link to different requests to the same client.

I can’t follow this sentence, particularly the part with the word “to”
repeated three times.  Please reword it.

   Clients only send Echo to the same
   server from which they were received.

The only possible antecedent to “they” here is “clients”, which is clearly
wrong: you mean “Echo”.  So this needs rewording.  Maybe use “Echo
options”, or something like that.

— Section 8.2 —
I’m having a hard time deciding whether some of these references should be
normative, especially 8613.  Please give these another review with that in
mind and see if you think any of them should be moved.  You can find some
guidance in the relevant IESG Statement <
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/>,
keeping in mind the general rule that something that needs to be fully
understood should be normative, while something that just adds extra
enlightenment can be informative.

— Appendix A —

   security against an attacker guessing echo values is given by s = bit
   length of r - log2(n).

What is “r”?

   A server MAY want to encrypt its timestamps

I suggest that a server doesn’t “want” to do anything.  Perhaps it’s better
to say, “It might be important to encrypt a server’s timestamps (see
Section 6)”.

— Appendix B —

   repeated transmission failure; in DTLS, if no packages are lost)

Should that be “packets”?

   In those situations, no message has any Request-Tag option set, and
   that can be recycled indefinitely.

I don’t understand what is being “recycled” if you’re not using he
Request-Tag option (also applies to the subsequent sentence).

—
Barry