Göran Selander
2018-03-30 10:44:38 UTC
Hello,
We have submitted a new version of OSCORE which we believe addresses the
remaining comments from IESG and Martin Thomson's detailed comments.
Judging by the reviews there was a need for further clarifications so some
effort has been spent in rephrasing and spelling out the assumptions and
processing steps. This resulted in quite a few changes, see below, but
most are about providing more explanations.
Meanwhile we received some detailed comments
(https://github.com/core-wg/oscoap/issues/220) from a new implementer that
we have also addressed.
The changes are:
- Ekr's comments on the term "binding" of response to request required
further clarifications on the assumptions of the server.
- Renamed the option and header field "OSCORE" as agreed in the F2F
meeting.
- Restructuring: collecting text of related content in one place;
reordering of sections and changing names of section headings
- Notification replay protection was overly restrictive compare to RFC
7641, which does not require dropping all but the freshest. Other Observe
intermediary processing.
- Removed the "*" from Figure 5: this information is redundant since there
is a section describing the special options.
- The response code to the dummy FETCH was changed from 2.04 to 2.05,
which could otherwise confuse intermediaries.
- Simplifying processing when storing sequence number to persistant
storage.
- An example of web linking (requested by Martin Thomson).
- Split of section "10. Proxy and HTTP Operations" into "10. CoAP-to-CoAP
Forwarding Proxy" and "11. HTTP Operations”. The latter was restructured
to avoid repetition of processing steps.
- Correction of the applicability of HTTP Vary: this is not relevant when
OSCORE messages are transported with HTTP since a cached message is not
useful for any other client.
- Defining the Content-Format value for the OSCORE Media-Type as agreed in
the f2f meeting.
- Expanded on security context establishment (requested by Kathleen
Moriarty)
- New section on Master Secret. Requirements on Master Secret was overly
restrictive, does not have to be uniformly distributed.
- Moved section on "client aliveness" from appendix into security
considerations
- Replaced detailed quantification of security level valid under certain
assumptions with property of the nonce construction.
- Caveat on master salt reuse
- More detailed considerations on unprotected headers.
Regards,
Göran
We have submitted a new version of OSCORE which we believe addresses the
remaining comments from IESG and Martin Thomson's detailed comments.
Judging by the reviews there was a need for further clarifications so some
effort has been spent in rephrasing and spelling out the assumptions and
processing steps. This resulted in quite a few changes, see below, but
most are about providing more explanations.
Meanwhile we received some detailed comments
(https://github.com/core-wg/oscoap/issues/220) from a new implementer that
we have also addressed.
The changes are:
- Ekr's comments on the term "binding" of response to request required
further clarifications on the assumptions of the server.
- Renamed the option and header field "OSCORE" as agreed in the F2F
meeting.
- Restructuring: collecting text of related content in one place;
reordering of sections and changing names of section headings
- Notification replay protection was overly restrictive compare to RFC
7641, which does not require dropping all but the freshest. Other Observe
intermediary processing.
- Removed the "*" from Figure 5: this information is redundant since there
is a section describing the special options.
- The response code to the dummy FETCH was changed from 2.04 to 2.05,
which could otherwise confuse intermediaries.
- Simplifying processing when storing sequence number to persistant
storage.
- An example of web linking (requested by Martin Thomson).
- Split of section "10. Proxy and HTTP Operations" into "10. CoAP-to-CoAP
Forwarding Proxy" and "11. HTTP Operations”. The latter was restructured
to avoid repetition of processing steps.
- Correction of the applicability of HTTP Vary: this is not relevant when
OSCORE messages are transported with HTTP since a cached message is not
useful for any other client.
- Defining the Content-Format value for the OSCORE Media-Type as agreed in
the f2f meeting.
- Expanded on security context establishment (requested by Kathleen
Moriarty)
- New section on Master Secret. Requirements on Master Secret was overly
restrictive, does not have to be uniformly distributed.
- Moved section on "client aliveness" from appendix into security
considerations
- Replaced detailed quantification of security level valid under certain
assumptions with property of the nonce construction.
- Caveat on master salt reuse
- More detailed considerations on unprotected headers.
Regards,
Göran
A new version of I-D, draft-ietf-core-object-security-12.txt
has been successfully submitted by Göran Selander and posted to the
IETF repository.
Name: draft-ietf-core-object-security
Revision: 12
Title: Object Security for Constrained RESTful Environments (OSCORE)
Document date: 2018-03-30
Group: core
Pages: 72
https://www.ietf.org/internet-drafts/draft-ietf-core-object-security-12.tx
t
https://datatracker.ietf.org/doc/draft-ietf-core-object-security/
https://tools.ietf.org/html/draft-ietf-core-object-security-12
https://datatracker.ietf.org/doc/html/draft-ietf-core-object-security
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-object-security-12
This document defines Object Security for Constrained RESTful
Environments (OSCORE), a method for application-layer protection of
the Constrained Application Protocol (CoAP), using CBOR Object
Signing and Encryption (COSE). OSCORE provides end-to-end protection
between endpoints communicating using CoAP or CoAP-mappable HTTP.
OSCORE is designed for constrained nodes and networks supporting a
range of proxy operations, including translation between different
transport protocols.
Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
has been successfully submitted by Göran Selander and posted to the
IETF repository.
Name: draft-ietf-core-object-security
Revision: 12
Title: Object Security for Constrained RESTful Environments (OSCORE)
Document date: 2018-03-30
Group: core
Pages: 72
https://www.ietf.org/internet-drafts/draft-ietf-core-object-security-12.tx
t
https://datatracker.ietf.org/doc/draft-ietf-core-object-security/
https://tools.ietf.org/html/draft-ietf-core-object-security-12
https://datatracker.ietf.org/doc/html/draft-ietf-core-object-security
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-object-security-12
This document defines Object Security for Constrained RESTful
Environments (OSCORE), a method for application-layer protection of
the Constrained Application Protocol (CoAP), using CBOR Object
Signing and Encryption (COSE). OSCORE provides end-to-end protection
between endpoints communicating using CoAP or CoAP-mappable HTTP.
OSCORE is designed for constrained nodes and networks supporting a
range of proxy operations, including translation between different
transport protocols.
Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat