Code change:
Abstract This memo defines Object Security of CoAP (OSCOAP), a method for <del> application layer protection of message exchanges with the Constrained Application Protocol (CoAP), using the CBOR Object Signing and Encryption (COSE) format.  OSCOAP provides end-to-end encryption, integrity and replay protection to CoAP payload, options, and header fields, as well as a secure binding between CoAP request and response messages.  The use of OSCOAP is signaled with the CoAP option Object-Security, also defined in this memo. </del> <ins> application layer protection of the Constrained Application Protocol (CoAP), using the CBOR Object Signing and Encryption (COSE).  OSCOAP provides end-to-end encryption, integrity and replay protection to CoAP payload, options, and header fields, as well as a secure message binding.  OSCOAP is designed for constrained nodes and networks and can be used across intermediaries and over any layer.  The use of OSCOAP is signaled with the CoAP option Object-Security, also defined in this memo. </ins> 1. <del> The Constrained Application Protocol (CoAP) RFC7252 is a web application protocol, designed for constrained nodes and networks RFC7228.  CoAP specifies the use of proxies for scalability and efficiency.  At the same time CoAP references DTLS RFC6347 for security.  Proxy operations on CoAP messages require DTLS to be terminated at the proxy.  The proxy therefore not only has access to the data required for performing the intended proxy functionality, but is also able to eavesdrop on, or manipulate any part of the CoAP payload and metadata, in transit between client and server.  The proxy can also inject, delete, or reorder packages without being protected or detected by DTLS. </del> <ins> The Constrained Application Protocol (CoAP) is a web application protocol, designed for constrained nodes and networks RFC7228.  CoAP specifies the use of proxies for scalability and efficiency.  At the same time CoAP RFC7252 references DTLS RFC6347 for security.  Proxy operations on CoAP messages require DTLS to be terminated at the proxy.  The proxy therefore not only has access to the data required for performing the intended proxy functionality, but is also able to eavesdrop on, or manipulate any part of the CoAP payload and metadata, in transit between client and server.  The proxy can also inject, delete, or reorder packages without being protected or detected by DTLS. </ins> This memo defines Object Security of CoAP (OSCOAP), a data object based security protocol, protecting CoAP message exchanges end-to- end, across intermediary nodes.  An analysis of end-to-end security for CoAP messages through intermediary nodes is performed in I- D.hartke-core-e2e-security-reqs, this specification addresses the <del> forwarding case. </del> <ins> forwarding case.  In addition to the core features defined in RFC7252, OSCOAP supports Observe RFC7641 and Blockwise RFC7959. </ins> <del> The solution provides an in-layer security protocol for CoAP which does not depend on underlying layers and is therefore favorable for providing security for "CoAP over foo", e.g.  CoAP messages passing over both unreliable and reliable transport I-D.ietf-core-coap-tcp- tls, CoAP over IEEE 802.15.4 IE I-D.bormann-6lo-coap-802-15-ie. </del> <ins> OSCOAP is designed for constrained nodes and networks and provides an in-layer security protocol for CoAP which does not depend on underlying layers.  OSCOAP can be used anywhere that CoAP can be used, including unreliable transport RFC7228, reliable transport I- D.ietf-core-coap-tcp-tls, and non-IP transport I-D.bormann-6lo-coap- 802-15-ie. </ins> OSCOAP builds on CBOR Object Signing and Encryption (COSE) I-D.ietf- <del> cose-msg, providing end-to-end encryption, integrity, and replay protection.  The use of OSCOAP is signaled with the CoAP option Object-Security, also defined in this memo.  The solution transforms an unprotected CoAP message into a protected CoAP message in the following way: the unprotected CoAP message is protected by including payload (if present), certain options, and header fields in a COSE object.  The message fields that have been encrypted are removed from the message whereas the Object-Security option and the COSE object are added.  We call the result the "protected" CoAP message.  Thus OSCOAP is a security protocol based on the exchange of protected CoAP messages (see oscoap-ex). OSCOAP provides protection of CoAP payload, certain options, and header fields, as well as a secure binding between CoAP request and response messages.  OSCOAP provides replay protection, but like DTLS, OSCOAP only provides relative freshness in the sense that the sequence numbers allows a recipient to determine the relative order of messages.  For applications having stronger demands on freshness (e.g. control of actuators), OSCOAP needs to be augmented with mechanisms providing absolute freshness I-D.mattsson-core-coap- actuators. </del> <ins> cose-msg, providing end-to-end encryption, integrity, replay protection, and secure message binding.  The use of OSCOAP is signaled with the CoAP option Object-Security, defined in obj-sec- option-section.  OSCOAP provides protection of CoAP payload, certain options, and header fields.  The solution transforms an unprotected CoAP message into a protected CoAP message in the following way: the unprotected CoAP message is protected by including payload (if present), certain options, and header fields in a COSE object.  The message fields that have been encrypted are removed from the message whereas the Object-Security option and the COSE object are added, see oscoap-ex. </ins> OSCOAP may be used in extremely constrained settings, where DTLS cannot be supported.  Alternatively, OSCOAP can be combined with

Related discussion:
text: UTF-8 über alles.
Abstract: Explain that OSCOAP works across intermediaries and over any layer.Intro: Explain that OSCOAP works for Observe and Blockwise.Intro: Move details on replay and freshness to some other section.Terminology: Explain the references and add COSE.