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

From: Jim Schaad <[email-masked]>
Date: Wed, 10 Jul 2019 15:16:39 -0700

Here are some comments:

1.  The Abstract needs to say that it updates RFC 7252 - and it would be
nice if it summarized what it updated.

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

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?

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?

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.

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

7.  In section 2.3 - item 2 - star 2 - s/expect/except/

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.

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.

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.

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?

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.

jim

---

From: Christian Amsüss <[email-masked]>
Date: Thu, 11 Jul 2019 16:50:02 +0200

Hello Jim, Göran and John,

thanks for your comments, responses inline:

> 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/

> 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".

> 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.

> useful on this topic.  I think I understand the paragraphs about proxies as

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?

> 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

> 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".

> out what it is yet.  I'll continue to mull this one over.

Please do, that is a crucial section.

> two OSCORE blockwise operations meet these conditions as the path is hidden

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.

> option, if the option is visible to an attacker why would they need to forge

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?

> 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

---

From: Jim Schaad <[email-masked]>
Date: Thu, 11 Jul 2019 14:14:23 -0700

Christian, et al.

-----Original Message-----
From: Christian Amsüss <[email-masked]> 
Sent: Thursday, July 11, 2019 7:50 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; 'core' <[email-masked]>
Subject: Re: [core] WGLC draft-ietf-core-echo-request-tag-05

> 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".

[JLS] Perhaps

The Inner option is encrypted and integrity protected between the endpoints,
thus providing the freshness between the ultimate client and server.  The
Outer option is used by intermediate entities to provide for hop-by-hop
security as described for proxy operations in section 2.3.

> 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.

[JLS] I think that should be sufficient.  Now I just need to figure out how
to expose both of them as independent entities in my code.

> 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?

[JLS] No in this case I was thinking about the case of a proxy getting a
4.01 w/ an echo option and then, rather than returning that answer to the
client re-sending the request with the echo option added.  I don't think
this type of behavior is currently documented anywhere.  I am not sure if
the echo option should be added by the proxy just once or potentially
multiple times.

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

[JLS] I think that this has opened up for this type of cookie tracking even
without this change.  And should be noted in the privacy considerations

> 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.

[JLS] I think that cleans things up.

> 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.

[JLS] Still mulling.

> 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.

[JLS] I was referring to doing outer blockwise for OSCORE not inner
blockwise.  Does that change your opinion?

Jim

> 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".

> 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.

Best regards
Christian

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