Object Security for Constrained RESTful Environments (OSCORE)
RFC 8613

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

(Ben Campbell) Yes

Comment (2018-03-07 for -09)
No email
send info
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.

(Alexey Melnikov) Yes

(Kathleen Moriarty) Yes

Comment (2018-03-08 for -09)
No email
send info
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!

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Benoît Claise) No Objection

Alissa Cooper No Objection

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

(Spencer Dawkins) No Objection

(Suresh Krishnan) No Objection

(Mirja Kühlewind) No Objection

Comment (2018-03-07 for -11)
No email
send info
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?

(Terry Manderson) No Objection

(Eric Rescorla) (was No Record, Discuss) No Objection

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

Alvaro Retana No Objection

(Adam Roach) (was Discuss) No Objection

Comment (2018-03-14 for -10)
No email
send info
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>.

Warren Kumari No Record

Comment (2018-03-06 for -09)
No email
send info
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