Skip to main content

Object Security for Constrained RESTful Environments (OSCORE)
draft-ietf-core-object-security-16

Yes

(Alexey Melnikov)

No Objection

(Alia Atlas)
(Alvaro Retana)
(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.

Warren Kumari
No Record
Comment (2018-03-06 for -09) Unknown
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 IESG member
Yes
Yes (for -08) Unknown

                            
Ben Campbell Former IESG member
Yes
Yes (2018-03-07 for -09) Unknown
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 IESG member
Yes
Yes (2018-03-08 for -09) Unknown
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 IESG member
(was Discuss) No Objection
No Objection (2018-03-14 for -10) Unknown
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 IESG member
No Objection
No Objection (for -09) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2018-03-08 for -15) Unknown
Thanks for addressing the Gen-ART review. I did not have time to review this document unfortunately.
Alvaro Retana Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Eric Rescorla Former IESG member
(was No Record, Discuss) No Objection
No Objection (2019-03-09) Sent
Grr. No Objection
Mirja Kühlewind Former IESG member
No Objection
No Objection (2018-03-07 for -11) Unknown
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 IESG member
No Objection
No Objection (for -09) Unknown

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -09) Unknown