Subject: [Ace] OSCORE Profile status update and way forward

From: Francesca Palombini <[email-masked]>
Date: Mon, 21 Sep 2020 13:48:33 +0000

Hi all,

Following the discussions here and at the latest interim, I have submitted a new version of the OSCORE profile. This version addresses the last call/post last call comments: Gen ART review, the OPS Dir review, IANA comments and John's review. Diff here: https://tools.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-12.txt 

Re IANA comments, I have gone with Ludwig's suggestion and named the "location" for the new IANA parameters as "client-rs request" and "rs-client response". I think this is the clearest and simplest option. If there is no objection to those names, I will send the email to the DE on Wednesday.

Gen ART and OPS Dir review were mostly editorial with some bug fixes. To answer John's review, I have done some bigger changes, additional to what I consider editorial and clarifications. Main changes are summarized here:
- Master Salt construction for JSON/Base64 encoding is now specified. Examples for both CBOR and JSON are added.
- added a requirement: clarified that the AS MUST send different OSCORE Input Material to different clients
- added security considerations on one client using the same OSCORE Input Material with different RS
- removed AS discovery mechanism (this is just inherited from the framework)
- clarified that Appendix B.2 of OSCORE can be used with this profile, and what implementers need to think about if they do.
- renamed OSCORE_Security_Context into OSCORE_Input_Material

I consider all of John's comments addressed, with two exceptions: 
a. renaming clientId and serverId, as that was discussed previously and I don't see a better option for it, and 
b. the id negotiation mechanism. As discussed in the meeting, I worked on several options to add the identifier negotiation mechanism: 

1. define an additional optional mechanism that would work on top of the existing OSCORE profile if both nodes support it. Because such a mechanism is optional, attackers in the middle could easily make the nodes roll back to OSCORE without this mechanism, which is why I don't think this is the optimal solution
Draft: https://tools.ietf.org/html/draft-palombini-ace-oscore-profile-id-00 

2. define an OSCORE profile v-2 which is equal to the existing OSCORE profile + adds the negotiation mechanism. Much more thought is needed about how these two different profiles interact (can the client try to run a v2 profile if it receives a v1 token? How does the RS react if it does support v1 but not v2? ), but it seems to me that it becomes very complicated to try to cover all cornercases and profiles overlap. Moreover I was hoping for a simple, short document. It is not.
Draft: https://tools.ietf.org/html/draft-palombini-ace-oscore-profile-v2-00 

3. include the identifier negotiation mechanism in the profile itself. I implemented this in a separate branch in the github: https://github.com/ace-wg/ace-oscore-profile/tree/id-negotiation . You can see the diff with the draft here: https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-ace-oscore-profile.txt&url2=https://ace-wg.github.io/ace-oscore-profile/id-negotiation/draft-ietf-ace-oscore-profile.txt 
Considered the changes which have already happened as a consequence of last call reviews, it might be worth for the working group to consider this option, although it is a major change conceptually to the document. You can see that the changes are not huge, it actually removes a lot of text.

We welcome opinions from everybody in the wg, and guidance from our chairs and AD on what's the best way to move forward at this point.

Francesca