DICE BOF Minutes: note well (Carsten) agenda, problem space, how it all fits into IETF (Zach) - DTLS 1.2 as chosen security mechanism of CoAP - implementers came back with problems -> profiling & secure group communication - CoAP & LWIG: requirements - TLS: expertise Zach: DTLS is the right choice for CoAP. A lot of applications requires group communication. This is a security area working group. Scope are: defining a constrained DTLS profile for a specific use case in IoT. and define DTLS record layer group communications with a pre-defined group keys. Minimize the impact on DTLS record layer. Explicitly out of scope. Do not want to change DTLS, do not do key management and do not specify new ciphersuites. This work relates to CoRE, LWIG and TLS. This work is complementary to LWIG. There may be future work, e.g., new transport for TLS over CoAP, use of more efficient cipher suites, revocation and ACL management. DTLS profiling efforts (Hannes) - scenario requirements vs. protocol complexities -- recommend subset of available protocol functionality -- detail implied security considerations - example scenario and profiling aspects (Zach) Hannes Tschofenig - DTLS Profiling for IoT - require information about the expected use cases. Zach - For example a simple use case (OMA Lightweight) can be used. Secure Group Communication (Sandeep) - CoAP: only unicast security, but specifies group communication - reuse DTLS record layer with pre-configured group keys (out-of-band) - strawman proposal: split DTLS sequence number for group communication into sender id and seq number -- Q: sender id must be unique in order not to break security for some cipher suites -- A: Must be considered. -- Q: DoS protection? E.g., make multiple group communication clients reply to single request in order to drain battery. -- A: Should be considered. Sandeep Kumar - Group Communication using Record Layer - One example industrial use case is lighting control. - main requirements are group level data integrity and authentication, confidentiality and replay protection. - do not change the handshake and do not specify how to do group key management. - a strawman proposal is to split the sequence number in the Record layer into 2, a 2-byte sender-ID, and 4-byte sequence number. David McGrew - the sender ID will be used in the initialization vector. - the initialization vector includes the sender ID. The CCM requires the nonce to be unique, and we have to make sure that the sender ID is unique. Goran - Have you looked at the Denial of Service aspect in IoT? Zach - good point, this can be incorporated into the profiling work. Shahed Raza - Is there any indication that DTLS is the right choice for IoT? Why not IKE or HIP? Hannes - CoRE WG had chosen DTLS to secure CoAP. Which protocol to choose is not the scope of this WG, as it had already been chosen. Maybe that question should be addressed elsewhere. Sahead Raza - DTLS is for the transport, and very hard to do key management for link-layer and layers below. Hannes - Find interested people who are willing to work on IKE for IoT, and propose some work in IETF. Carsten - there is a document in CoRE that describe the use of IKE for CoAP, but there wasn't enough interest. Sahead Raza - Since we are not going to change anything in the DTLS, there is a change in TLS that cookie size is increased to 255 bytes. Ekr - cookie is variable length, not fixed 255 length. There is no reason that you cannot use smaller cookie. The expectation is that TLS will work together with this DICE. If there's a request coming from this group to TLS, TLS will try to accomodate it. Robert cragie - in Zigbee IP, we profile for different application. Is this profile just for constrained environment or how to guarantee interoperability Zach - yes this is for constrained environment, and to ensure interoperability, this is a standard track RFC. - network access is out of scope of DICE. Authorization work in Core could help. Cullen Jenning - small implementation of 12K of TLS. Zach - if you have any contribution on implementation experience, please contribute to LWIG. Goran - when making profile, you need to make some design choices, will new extensions and new ciphersuites be considered in this WG? Carsten - We have a fixed use case, depending on the future if there are other use cases, then new extension and profiles can be considered. Zach - not excluding the extension that you can use for a particular profile implementation. There is a possibility to recharter to include other use cases. Goran - what is the process of defining a new use case? David McGrew - this group should provide valuable input to TLS 1.3. - TLS certificate type that might be useful? would this be a RFC in this working group. Carsten - not sure. Paul Hoffman - this can be done by any individual. Ekr - between now and next 6 months, this group can provide input to TLS 1.3 Carsten - Important Questions: (a) - LOTS (b) - no (C) - no Charter question (a) - 20 (b) - 0 Andrew - impressed with the clarity of the charter. Why do we need a separate working group? Zach - We tried to do security in CoRE, it hasn't been successful, there are a lot of noise about web. CoRE is an APP area, and not security area. - pressure Ekr to take up this work, but that has not been successful. - Hasn't been able to find a WG to take up this work. Paul Hoffman - There is a "spin-out" working group that might be useful. Reverse the charter, and mention about the group communication first, then do the profile. - if this is a very short live WG, then that might release some overhead. Stephen - There might be some topics that you might want to recharter, and wants to keep this as SEC area, and prefer it to be a WG. Zach - pretty neutral on the order of work items. David McGrew - shouldn't there be a specific item for providing inputs to TLS WG? Zach - hesitant to have a milestone defined. Can definitely add as an item of work we do. Carsten - generating requirement documents for TLS is a tedious work. Do not want to have a formal milestone. David McGrew - people are dying for requirements and real world data, and they can be valuable. Robert Cragie - How easy do you think it will be to define A profile for a particular architecture? Zach - Remove the word architecture and use - use cases. Carsten - important questions (a) - 30 (b) - 0 (c) - 0 Final Question edit document - 10 comment - 30 implement - 18