Skip to main content

Object Security for Constrained RESTful Environments (OSCORE)
RFC 8613

Yes

(Alexey Melnikov)

No Objection

Alvaro Retana
(Alia Atlas)
(Benoît Claise)
(Deborah Brungard)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

No Record


Note: This ballot was opened for revision 08 and is now closed.

Alvaro Retana No Objection

Warren Kumari No Record

Comment (2018-03-06 for -09)
Unfortunately, I ran out of time to properly ballot / review - I'd like to point the responsible AD at Erik Vyncke's OPS-DIR review (and the response) at https://www.ietf.org/mail-archive/web/ops-dir/current/msg03116.html

(Alexey Melnikov; former steering group member) Yes

Yes (for -08)

                            

(Ben Campbell; former steering group member) Yes

Yes (2018-03-07 for -09)
I’m balloting “yes”, but I have a few very minor comments:

Substantive Comments:

§4.2.2, last paragraph: Why not specify that directly, rather than put a normative requirements on new specifications?

Editorial and Nits:

§4.2.3.1, 2nd to last paragraph:
Last sentence is hard to parse.

§5, third paragraph:
I don’t think that spec claims “plaintext” means “data that is encrypted and integrity protected”. I think it means “ the clear text input that will be encrypted and integrity protected” (This could probably be fixed by changing “data that is” to “data to be”.)

§8.1, last paragraph: The SHALL seems more like a statement of fact than a requirement.

(Kathleen Moriarty; former steering group member) Yes

Yes (2018-03-08 for -09)
I strongly support an object level security solution to provide end-to-end security when traffic traverses proxies or is relayed in the case of many IoT scenarios.  There are billions of devices in the IoT space with different constraints and operating requirements.  As such, I support and appreciate your work on this draft.  I had already known that this work was decoupled from EDHOC and appreciate that it can now be used either with TLS, EDHOC, or some other transport security protocol to offer object level security and protection in transit for data.

Thanks for addressing the OpsDir review a couple of weeks ago that pointed out where the work for provisioning the master secret, use of pre-shared keys in some scenarios, the use of profiles for algorithm agility, and the candidate key exchange protocols are done and other questions on security considerations and MTI.  Since EKR's review pointed some of these same things out, having the pointers more clearly stated in the draft would be beneficial to the reader and implementer.  Perhaps a longer discussion is needed in the draft. Where there are still multiple candidate drafts, you may not want to name one yet, but rather point to existing work.  Thanks again!

(Adam Roach; former steering group member) (was Discuss) No Objection

No Objection (2018-03-14 for -10)
Thank you for addressing my DISCUSS and comments.

I continue to support EKR's DISCUSS and Martin Thomson's list of issues <https://mailarchive.ietf.org/arch/msg/ietf/xtYOveSgAf32EoHVOV_E08brN54>.

(Alia Atlas; former steering group member) No Objection

No Objection (for -09)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (2018-03-08 for -15)
Thanks for addressing the Gen-ART review. I did not have time to review this document unfortunately.

(Benoît Claise; former steering group member) No Objection

No Objection (for -09)

                            

(Deborah Brungard; former steering group member) No Objection

No Objection (for -09)

                            

(Eric Rescorla; former steering group member) (was No Record, Discuss) No Objection

No Objection (2019-03-09)
Grr. No Objection

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2018-03-07 for -11)
This sentence in the intro sounds rather speculative to me:
"An extension of OSCORE may also be used to protect group
   communication for CoAP [I-D.tiloca-core-multicast-oscoap]. "
Maybe just remove it?

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -09)

                            

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -09)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (for -09)