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

[Jim Schaad <[e-mail]>]

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