Contributing OSCORE to Californium. #516
Comments
|
Would it be a separate module? Eclipse has a contribution process: I guess, it's covered by page 3 and would therefore require a CQ. |
|
Hi @LudwigSeitz, as @boaks already pointed out, the current Cf committers' time is very limited and their main interest therefore currently lies on stabilizing the existing functionality and finishing the upcoming 2.0.0 release. That said, we are always interested in extending Cf's capabilities, we only need to make sure that the code that is getting contributed will be maintained accordingly. So, FMPOV the way we can/should proceed mainly depends on how big an impact your contribution will have on existing code and what your plans are regarding your future involvement in Cf. What we would like to prevent is ending up in a situation where the contributed code does not receive any more love after the contribution has been made ... WDYT? |
Just includes my expectation, that even if OSCORE will be release as standard, there usually will arise question, especially for compatibility and interpretation of that standard. And "maintaining" exactly means to cover that. |
|
Some answers (more to come):
|
|
And you're aware, that we mainly work on |
|
No, but good to know, I'll merge and see what difference it makes. |
|
On maintaining OSCORE for Californium: Ericsson is financially supporting |
|
Sounds good! FMPOV, if the hooks in core are limited, and the main stuff goes to a own (optional?) module, I'm fine with it. So I'm looking forward to your contributions. |
|
On optional: Yes, OSCORE is invoked with a new CoAP Option (called Object-Security) so is optional to use. |
|
Ok checked the 2.0.x stuff. Doesn't seem to be a major issue. We are now working on extricating our code into a module. I'm also looking into the legal contribution process, can someone point me to the "Committer Tools" where I need to fill out the Contribution Questionaire? |
|
@sophokles73 |
|
Would any one of you be able to spare the time for a short telco, to help us getting started with the first steps of the eclipse contribution procedure? The pdf @boaks linked to is a pretty intimidating place to start with. You can reach me at ludwig.seitz@ri.se |
|
Hi Ludwig,
sure, the Eclipse processes are not for the faint of hearted ;-) I'll get in touch with you next Monday. No worries, we'll get this done ...
Kai
On 26.01.2018 14:44, LudwigSeitz wrote:
Would any one of you be able to spare the time for a short telco, to help us getting started with the first steps of the eclipse contribution procedure? The pdf @boaks<https://github.com/boaks> linked to is a pretty intimidating place to start with. You can reach me at ludwig.seitz@ri.se<mailto:ludwig.seitz@ri.se>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#516 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AFaz1yEu-CINAq0xYCoLSi3Ll_Pv--Qtks5tOdasgaJpZM4RXnAm>.
…--
Mit freundlichen Grüßen / Best regards
Kai Hudalla
Chief Software Architect
Bosch Software Innovations GmbH
Ullsteinstraße 128
12109 Berlin
GERMANY
www.bosch-si.com<http://www.bosch-si.com>
Registered Office: Berlin, Registration Court: Amtsgericht Charlottenburg; HRB 148411 B
Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors: Dr. Stefan Ferber, Michael Hahn
|
|
@LudwigSeitz Where can I find the repo for OSCORE CoAP? I am working on adding OSCORE for BACnet/IT, this would be really useful to perform some tests using object security. Thank you! |
|
I assume this is the repo for OSCORE CoAP with latest changes https://bitbucket.org/lseitz/oscoap_californium.git |
|
The dev code can be found in this fork: https://bitbucket.org/lseitz/oscore |
|
Merging PR #679 makes now a basic OSCORE implementation available. Unfortunately, the tests have revealed, that COSE uses/requires java 1.8, and so OSCORE can only be used, if java 1.8 is used. For the other modules of californium we still want tu support java 1.7, therefore we run the unit test using java 1.7 which fails for OSOCRE. For now, I therefore skip the unit tests in the OSCORE pom, if java before 1.8 is used. |
|
I don't think Java 1.8 is a hard requirement, I'll talk with Rikard and see if we can remove that. |
|
For the oscore module, I removed the java 1.8 dependency (Integer.BYTES) already. |
|
I was under the impression that we had removed the dependency on the COSE lib. Let me double-check. |
|
At least, the COSE pom compiles for target 1.8 and push that to maven central ... |
|
My understanding is that Tobias extracted two files from the COSE library (Encrypt0Message.java & EncryptCommon.java) to be able to do some modifications to how the encryption is performed. But those files in turn have the COSE com.augustcellars.cose library as dependency and it is needed for the COSE functionality, and thus the OSCORE code requires Java 1.8. So to make the code work with Java 1.7 I suppose there could be three options.
Those points may be difficult to accomplish. If we cannot make the COSE library support Java 1.7, is it possible to have it so OSCORE is available but only for people running Java 1.8? |
|
That's also my understanding.
That's also my opinion. Therefore I made the test for OSCORE depend on java 1.8. |
|
I have had some discussions with Ludwig and he has managed to create an alternative implementation of the OSCORE code that does not require Java 1.8. To achieve this we manually extract the specific files we need from the COSE (com.augustcellars.cose) library and because of that it is no longer a dependency for the code, and due to this it can now run on Java 1.7. Is it better to let the current PR go through and then make a new PR with the code to allow running under Java 1.7? Or is it better to amend the current PR with the updated code? |
|
The nasty kickback of copy and modify would be, that update and bugfixes are hard to manage. Hope, it doesn't happen too often.
The "current PR" is merged. So, please fetch the current 2.0.x head and prepare your changes based on that. When you ready, create a new PR. |
|
Okay, I see. Then we can proceed like that and submit a new PR to make the code able to run both under Java 1.7 and 1.8. |
|
We don't expect many changes in the COSE code. It has gone through a number of interoperability tests and the standard is published and seems stable. If I interpret your (boaks) comments correctly, you are not fundamentally opposed to this solution? |
You know the COSE code better, so it's up to you.
OK, but I guess, this will be more than 1000 lines, so be patient, when your PR is ready, it will require a next CQ :-). |
|
754 new lines of code for including the necessary files from the COSE-Java lib. So I take it no CQ will be needed? |
|
754 would be great. |
|
Just on OSCORE versions: -16 has passed IESG review. |
|
Thanks for the update!
If full names should be included, please let me know, which one to use! |
Thanks, for the full name of RISE you could put RISE Research Institutes of Sweden. |
|
Hello, referring to the old discussion in this thread regarding "experimental", can you confirm if the OSCORE currently available in release 3.x is meant for production use. Thanks all! |
|
Usually I try to list the state of the several RFCs in our Eclipse/Project-Page. The main question for me is, what you assume to be relevant for using OSCORE in production.
Or what makes something for you "meant for production"? Should I reopen this issue? Or may be you create a new issue for OSCORE with your questions about "meant for production"? Maybe others have more information. (My personal commitment is still the same as on begin of 2018.) |
|
Thanks @boaks. Good to know. We are in learning phase of OSCORE and were looking for libraries. Will log a seperate issue, in case of any queries. |
|
You're welcome. Usually there is a set of reason, why to chose one technology. Just in order, that your choice is not that fixed, you may have a look at DTLS 1.2 with CID. That's implemented. And comes with The client libraries are currently under develop, mbedtls requires to get updated to the latest (hopefully final) version of the RFC. |
|
@rikard-sics: Would you like to share some information on the status of OSCORE for Cf? |
|
Our choice of OSCORE was due to its "End to End encryption", which is especially useful when there are multiple hops between client and server. Thanks for the suggestions. I believe, OSCORE is still the right choice for us. Please correct me if wrong. |
|
"End to End encryption": In both cases the IP and UDP message itself is not encrypted (at least not generally), but the UDP-payload is (DTLS, at least some parts), or the coap-message (OSOCRE, at least some parts). Anyway, everyone should go for the technology, which matches best. If "hops" are coap-proxies, then that "hop" requires to see the coap-message (at least some parts of it). |
|
Hello. Let me jump in with some comments from my side. I have been working as the main contributor of OSCORE to Californium. It is true that OSCORE does provide end-to-end security (of the CoAP payload, CoAP code and many of the CoAP options (Option list)). This can allow OSCORE to be used via a CoAP proxy without exposing the payload and many of the options. There is also code as part of the JUnit tests showing how OSCORE can be ran between a client and server via a proxy. Some points that @boaks listed: |
|
@boaks Thanks for this. Our requirement is to cover both cases.
@rikard-sics Thank you. Glad to know. |
|
Just adding to @boaks on the different properties of DTLS and OSCORE. DTLS is targeting protection of UDP payload. OSCORE targets protection of REST operations independent of transport, so allows efficient end-to-end protection in a mix of HTTP/CoAP over various transports. DTLS 1.2 was published in January 2012 and is widely deployed. OSCORE was published in July 2019 and is a part of a new suite of lightweight security protocols. During the period between these publications the benefits of low security overhead in particular for IoT applications was understood and this is reflected in OSCORE (and later in the record layer of DTLS 1.3), see e.g.: Looking ahead, both DTLS 1.2 and OSCORE are complemented with a lightweight version of OAuth 2.0 for authorization and access control in constrained environments (ACE) which is expected to soon become an IETF standard. Another progressed standardization activity in the IETF is OSCORE protection of group communication, e.g. protection of CoAP over multicast IP, which is an extension of RFC 8613. The ACE framework is also be used for authorizing access to the crypto keys in a group running OSCORE. There is also an extremely lightweight security handshake protocol in development (LAKE) significantly reducing the overhead of TLS/DTLS 1.2 & 1.3 handshakes. These latter components are still work in progress in the IETF although there are some implementations tested for interoperability. Hope that helps. |
That's interesting. I didn't follow the specification process in the last months (years :-) ) . If I remember well, at least the initial versions seems to stick on coap artifacts in order to create a nonce (but I may be wrong). I'm wondering how that will make it into the http stuff. Are there working examples, which demonstrates the e2e encryption over a coap2http cross proxy? |
|
Should I reopen this issue in order to try to include more people into the discussion about the use-cases? |
I can't recall if this was tested during the interop testing of RFC 8613 but the basic example is in the RFC so should be straightforward to try out with access to a proxy implementation. There are examples of both HTTP-CoAP and CoAP-HTTP, here is the latter: The end-to-end REST functionality was requested by Open Connectivity Foundation and the delegate was involved in the design.
I don't follow you there, which nonce is that? |
I don't think that is necessary for now. It is a good that Cf has both DTLS and OSCORE functionality and as long as people seem to find it and questions are answered then mission is accomplished. |
I may remember that wrong ;-). I never read it deep enough,
I see now, it requires something as a plugin for the HTTP-server (or an application, which can handle it). |
|
Let me come back to the current state of the OSCORE implementation for the projects status page
If wanted, we can adapt the text. Please provide a proposal. |
Yes, sounds good to update the description. Let us have a discussion internally on this and I can come back with a proposal before Friday. |
|
Just let me know, when you come to a conclusion and proposal. |
|
Let me add a remark about the API considerations: Overall, many APIs in Californium are not that clear, if that belongs to something as the "public API" intended for general users, or a special extension, intended for special usage and may be required to change without major release. I would appreciate, if you could check your API, and see, if the part, which should be used for general use-case is stable in your opinion. From my experience, that sometime leads to develop just a new version of the module in parallel, as I did e.g. for the cf-proxy, I just added cf-proxy2 and deprecated the old one. That gives time to the users to migrate. An other idea would be, if there large changes coming (e.g. the development in the scope of leshan), that first this changes are integrated and then the state of cf-oscore is changed. I don't have an overview about the usage of the current cf-oscore. So, if the API changes too much, it may be also considered to put that new work on a cf-oscore2. FMPOV, just all "to be discussed". |
After some internal discussions we arrived at the following text:
If that sounds good to you we could go with that. Let me get back to the points in your latest post. |
|
Replacing
with
or
? |
We were thinking simply replacing the entire current text with the following: |
|
OK. |
|
Though for some other features I added the californium version, I added a 3.5.0 for it. |
Hello team,
some of my colleagues and I would like to contribute OSCORE to Californium.
OSCORE defines the use of Object Security for CoAP using COSE, and is an alternative to DTLS, in scenarios where you have intermediary proxies that you do not trust fully.
OSCORE is an IETF working group draft that is currently in working group last call. There are a number of implementations out there, among which one we have done on top of Californium as a demonstrator.
We would like to bring that code up to your standards and contribute it to Californium, how do you suggest that we proceed?
The text was updated successfully, but these errors were encountered: