Draft: draft-ietf-core-object-security

Commentary: UTF-8 über alles . 
 Abstract : Explain that OSCOAP works across intermediaries and over any layer .  : Explain that OSCOAP works for Observe and Blockwise .  : Move details on replay and freshness to some other section . Terminology : Explain the references and add COSE .
Paragraph (version A):
This memo defines Object Security of CoAP (OSCOAP), a method for
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.
Paragraph (version A):
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.
Paragraph (version A):
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
forwarding case.
Paragraph (version A):
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.
Paragraph (version A):
OSCOAP builds on CBOR Object Signing and Encryption (COSE) I-D.ietf-
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).
Paragraph (version A):
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.
Paragraph (version B):
This memo defines Object Security of CoAP (OSCOAP), a method for
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.
Paragraph (version B):
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.
Paragraph (version B):
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
forwarding case.  In addition to the core features defined in
RFC7252, OSCOAP supports Observe RFC7641 and Blockwise RFC7959.
Paragraph (version B):
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.
Paragraph (version B):
OSCOAP builds on CBOR Object Signing and Encryption (COSE) I-D.ietf-
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.
Paragraph (version A):
Readers are expected to be familiar with the terms and concepts
described in RFC7252 and RFC7641.  Readers are also expected to be
familiar with RFC7049 and understand I-D.greevenbosch-appsawg-cbor-
cddl.  Terminology for constrained environments, such as "constrained
device", "constrained-node network", is defined in RFC7228.
Paragraph (version B):
Readers are expected to be familiar with the terms and concepts
described in CoAP RFC7252, Observe RFC7641, Blockwise RFC7959, COSE
I-D.ietf-cose-msg, CBOR RFC7049, CDDL I-D.greevenbosch-appsawg-cbor-
cddl, and constrained environments RFC7228.