Subject: [core] Chair's review of draft-ietf-core-echo-request-tag-03.txt

From: Carsten Bormann <[email-masked]>
Date: Wed, 6 Feb 2019 15:58:02 +0100

In preparation for the impending working-group last call, I have
reviewed draft-ietf-core-echo-request-tag-03.txt.  Substantive
comments are below; a set of small editorial comments is going to the
authors in parallel.

Grüße, Carsten

# Major

Completely outlawing token reuse is throwing out the baby with the
bathwater -- requiring stable storage for token numbers even in
situations where that is not needed.  (Of course, if you have that,
keeping a token counter e.g. per DTLS connection is a great
implementation strategy.)  Instead, the recommendations about Token
reuse should be specific to the cases covered.  This does require some
additional work.  (The actual wording in Section 5 is closer to
reason, but the introductory material gives a different impression.)

The wording in Section 5 needs to be clarified that this is a
requirement on clients, not a license to servers to base their
operations on the assumption that this requirement is always fulfilled
by a client -- the token processing rules of RFC 7252 still apply.

# Minor

* The document fails to mention that the "echo" function can also be
  provided at the application layer, e.g., with freshness tokens in
  "forms", as they are widely used with HTTP.  It should make clearer
  that "Echo" is just a convention to provide these freshness tokens, in
  particular when there is no natural way to keep the freshness tokens
  in the application data.

* Is "operation" the term we want to use henceforth?

* The "MUST NOT process" in 2.2 is weird, as it is qualified by the
  undetermined "has freshness requirements".  Maybe the text should
  focus on the concept of "fresh enough", which would also explain the
  license for the client to re-use Echo values in further requests.
  The time-based processing model ("RTT < T") is one way to handle
  "fresh enough", but certainly not a MUST -- there are event-based
  freshness models.

* 2.2: Clarify "The CoAP client side of HTTP-to-CoAP proxies SHOULD
  respond to Echo challenges themselves"

* 2.3 item 2 (time and state sync) is very opaque; its statements have
  not been analyzed in this review.

* Section 3 is confused about Request-Tag Options and lists of those.
  Why was the option marked repeatable?
  Or, what is wrong with a non-repeatable Request-Tag Option that
  defaults to the empty string (as opposed to a repeatable one that by
  definition defaults to the empty array/"list")?

* Section 6 (Security Considerations) MUST NOT use BCP14 language.
  Move the mandates up to where they belong.  "Is not allowed" about
  implementation strategies also is weird requirements language (in
  particular when the prohibition is just a result on some other
  implementation choices that aren't really required).

* Requiring a monotonic clock is a consequence of the implementation
  model proposed (time-based freshness) and is not needed with other
  forms of freshness.  In any case, if the non-monotonisms are limited
  to below the freshness requirements (as they would be for most
  usages of civil time), the are inconsequential, so these security
  considerations require some qualification even when phrased as such.
  Monotonic vs. wall-clock is somewhat orthogonal to non-hackable
  vs. hackable, anyway.

* Appendix A could contain some help with the selection of n.

# Editorial

* Title and Abstract.  The title probably should mention CoAP.  The
  abstract might want to say what the introduction already says: This
  is for supporting specific use cases (i.e., not all use cases will
  need these additions).

* Introduction.  The introduction could say earlier that Request-Tag
  is intended exclusively for combination with Block1 options.

* Section 2 would benefit from discussing freshness as a concept
  first, and then introducing the Echo Option as one convention to
  achieve the objectives.  In particular it should be clear that the
  rendition of Echo with a 4.01 may be an unusual case in many
  applications.

* Section 3 would benefit from explaining that Request-Tag is only
  meant to be used with Block1 Options in requests.

---

From: Christian M. Amsüss <[email-masked]>
Date: Wed, 20 Feb 2019 17:03:12 +0100

Hello Carsten,

thanks for the review, addressing the points that are not still being
processed by the authors:

> * Is "operation" the term we want to use henceforth?

Would "transfer" be more suitable? It's probably well-aligned with
RFC7959's use of the term to just give a precise definition again and
use that.

>   Why was the option marked repeatable?

The option is repeatable to allow tiny proxies to satisfy all their
blockwise-handling obligations by adding a per-sender Request-Tag
option. (The alternative would be that they string-append to any
existing Request-Tag option, which is somethign I'd perfer not to do as
an implementor).

That's outlined in section 3.5 but I agree that the wording is far from
straightforward.

>   is for supporting specific use cases (i.e., not all use cases will

Addressed in the next version.

>   is intended exclusively for combination with Block1 options.

Added.

Note that the Request-Tag option can be present in messages that carry
no Block1 option they are later messages of a combined Block1+Block2
oper..ransfer.

>   meant to be used with Block1 Options in requests.

Added (note as above). Is a MUST NOT be used in response messages
suitable there?

Thanks for your input
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: John Mattsson <[email-masked]>
Date: Wed, 27 Feb 2019 15:13:07 +0000

Hi Carsten,

Thanks for your review! There were a lot a good comments. I updated the GitHub version based on your comments.

https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-core-echo-request-tag.txt&url2=https://core-wg.github.io/echo-request-tag/draft-ietf-core-echo-request-tag.txt

>  is for supporting specific use cases (i.e., not all use cases will

Good suggestions, I have updated title and abstract.

>reason, but the introductory material gives a different impression.)

Very good with some feedback on this, I asked for that at an earlier interim. 

If the intro gave a different impression than the specification text, that is obviously wrong, I changed intro text to align with Section 5. The current specification text was chosen because it is easy to analyse that it is secure, easy to describe, and easy to implement correctly. It was also partly based on a comment from Klaus that token reuse caused all kinds of other non-security problems and should therefore in general be avoided. If we change the current text, what kind of specification text would you like?

- One option is to write a high level requirement that the client MUST NOT reuse a token if it can lead to a mismatch, and then give sequence number per traffic key as the recommended implementation strategy. But this is not very helpful for implementors as the problem is quite tricky to analyse. I updated the current github version to say:

"When CoAP is used with a security protocol not providing bindings between requests and responses, the tokens have cryptographic importance. The client MUST make sure that tokens are not used in a way so that responses risk being associated with the wrong request. The easiest 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. To avoid collisions the sequence number can be encoded with a fixed length or with some length-value encoding."

If we go this route I think we need to give more detailed guidance on when a token MUST NOT be reused. Such guidance would likely include the size of the lower layer replay window, a list of verified received responses, and whether Observe is used or not. It that worth doing?

I do not really see the problem with "requiring stable storage for token numbers even in situations where that is not needed", if you are using DTLS in a secure way you obviously store the DTLS sequence number already....

>by a client -- the token processing rules of RFC 7252 still apply.

Yes, I updated the text in Section 5 to clearly state that the updated requirement is on the client and that token processing for servers is not updated.

>  rendition of Echo with a 4.01 may be an unusual case in many

I made an attempt to discuss freshness as a concept first. Could you expand on how sending Echo in 4.01 would be unusual for applications?

>  particular when there is no natural way to keep the freshness tokens

Good point. Added new text saying just this.

>  Monotonic vs. wall-clock is somewhat orthogonal to non-hackable

Good points, agree that models are also valid and that non-monotonic time may be used. I softened the language conserning these aspects and added more guidance instead.

>  Move the mandates up to where they belong.  

Is this some new IETF guidance I have missed? Most RFCs (e.g. RFC 6347, RFC 7540, RFC 7252, RFC 8442) have BCP14 language in the security considerations... 

> * Appendix A could contain some help with the selection of n.

Good suggestions, I added some guidance.

-----Original Message-----
From: "Christian M. Amsüss" <[email-masked]>
Date: Wednesday, 20 February 2019 at 17:03
To: Carsten Bormann <[email-masked]>
Cc: "[email-masked] WG" <[email-masked]>, <[email-masked]>
Subject: Re: Chair's review of draft-ietf-core-echo-request-tag-03.txt
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, John Mattsson <[email-masked]>, <[email-masked]>
Resent-Date: Wed, 20 Feb 2019 08:03:31 -0800

Hello Carsten,

Added.

Thanks for your input
Christian