Re: [core] WGLC draft-ietf-core-echo-request-tag-05

[Christian Amsüss <[e-mail]>]

Hello Jim, Göran and John,

thanks for your comments, responses inline:

On Wed, Jul 10, 2019 at 03:16:39PM -0700, Jim Schaad wrote:
> 1.  The Abstract needs to say that it updates RFC 7252 - and it would be
> nice if it summarized what it updated.

The abstract says it updates the token processing of CoAP, but did not
explicitly mention its RFC. The pending updates now include a literal
mention of it, also making idnits a bit less suspicious.

> 2.  You can clean up the text dealing with core-object-security

With great pleasure.

As it's now final that OSCORE doesn't normatively reference ERT, a
line now has become 'Authors of other documents (e.g. applications of
{{RFC8613}}) are invited to mandate this behavior'. John, Göran, do we
want to pull [LwM2M] in there as an example?

[LwM2M]: https://www.omaspecworks.org/white-paper-lightweight-m2m-1-1/

> 3.  In section 2.1 - It is not clear to me why one would use an outer option
> for the echo option.   The inner one would be end-to-end and thus does the
> freshness thing.  What does the outer one do?

There are use cases for using Echo as an option in non-OSCORE
situations (eg. preventing traffic amplification attacks).

When OSCORE traffic passes through intermediaries (say, a reverse
proxy), those intermediaries will add Echo options on their own (first
answering 4.01 + Echo), prompting the client to create its OSCORE
request again with an outer Echo option.

In that, the Echo option is similar to the block options in that they
can occur around an OSCORE message, and need to be processed on the
outside and the inside independently of each other. Like there, a server
initiating it would normally set it as an inner option, but the client
must process it whereever it is.

It may be that we should find terminology more suitable for extension
authors than the U/I/E classes ("Start as E, process as either"?), but I
don't have a coherent proposal and don't think that this discussion
makes sense before we've gathered more experience classifying options.


The currently pending changeset includes as a clarification: "OSCORE
servers will usually (i.e. for the applications presented here) produce
Inner Echo options only, but clients need to process Outer ones
(typically generated by intermediaries) as well".

> 4.  In section 2.1 (or section 2.2) - There needs to be some text about
> where the echo options should be reflected in the event that either both
> inner and outer options are returned or just an outer is returned.  Can you
> use an inner w/o security for a new request?  I.e. is the inner echo value
> considered to be a security value?

The inner value is used as authenticated data, for example in receive
window recovery. I've added text elaboration on the current wording
of "and the Inner and Outer values are independent":

"When OSCORE is used, client and server MUST process Inner (Class E use)
and Outer (Class U use) Echo options independently. That is, a client
MUST NOT echo an Inner response value in an Outer request value or vice
versa, and the server MUST NOT accept Echo values from a different class
than where it sent it."

The case of both being present is rather exotic: that'd happen if the
origin server wants freshness, and the proxy adds a preemtive Echo
response option (instead of the regular 4.01 with Echo only and no
payload at all to curb amplification attacks). I'd consider the above
addition sufficient to spend another paragraph on how to handle the
presence of both and why that's rare, but can add one if there's
disagreement.

> 5.  Not sure if it is permissible for a proxy to modify the request in
> response to a 4.01 with an echo option or not.  Clarification might be
> useful on this topic.  I think I understand the paragraphs about proxies as
> servers.

An proxy may reject or modify a request for numerous reasons
(eg. unknown Unsafe options, client authentication prerequisites, hop
count decrements etc) -- are you asking for the rationale of the proxy's
license to inject outer Echo options and to reject forwarding (which we
AFAICT haven't provided in other documents), or did I misunderstand?

> 6.  In section 2.3 - item 1 star 2 - I would think that a server could
> proactively return an echo option even if the request did not come with one.
> Thus  GET - Content w/ echo - PUT w/ echo

I agree, generalized the text (John, Göran: or is there any reason not to?)

Thinking this through does open up the question of abusing Echo for
setting "Cookies", though; tracked as [41].

[41]: https://github.com/core-wg/echo-request-tag/issues/41

> 8.  In section 3 it says that the requests must be integrity protected, but
> in section 3.1 it says that this may be an outer option and is of class E
> not class I.  (And I recognize that it cannot be class I.)  I think that
> section 3 is probably the incorrect one.

That was probably my "in order to", now saying "The requests must be
integrity protected *if they should* protect against interchange of blocks
between different message bodies".

> 9.  I think that section 3.4.1 is missing something, but I have not figure
> out what it is yet.  I'll continue to mull this one over.

Please do, that is a crucial section.

> 10.  Section 3.4.2 - I think that it would be reasonable to highlight that
> two OSCORE blockwise operations meet these conditions as the path is hidden
> by security.

I had thought so initially as well, but given that the different
operations carry different OSCORE values (KID, PartIV) contained in
every block, they can't be confused anyway.

> 11. Section 6 - I am having problems with the idea of a forgery of an Echo
> option, if the option is visible to an attacker why would they need to forge
> it?

An attacker may try to circumvent traffic amplification protection
(predicting suitable Echo values w/o being able to intercept the
responses). Probably relates to the below "forgery" vs. "guessing".

For the other applications, I'm not sure they need to be that strict --
Göran, John, could you respond to this and the below items?

> 12. Appendix A - I think we have a different definition of forgery for list
> item 1.  I would have labeled this as guessing not forgery.  That is
> probably my security background talking.
> 
> 13. Appendix A - point 2 - The security is even higher if encryption rather
> than integrity is used here.

Thanks again for your input, we're processing the resulting changes in
[42], except for where other authors are mentioned by name.

[42]: https://github.com/core-wg/echo-request-tag/pull/42

Best regards
Christian


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