DICE BOF, IETF-87 Berlin

1. DTLS In Constrained Environments (DICE) BOF Wed 15:10-16:10, Potsdam 3 BOF Chairs: Zach Shelby, Carsten Bormann Responsible AD: Stephen Farrell Mailing List: dtls-iot@ietf.org DICE BOF, IETF-87 Berlin

2. Note Well This summary is only meant to point you in the right direction, and doesn't have all the nuances. The IETF's IPR Policy is set forth in BCP 79; please read it carefully. The brief summary: • By participating with the IETF, you agree to follow IETF processes. • If you are aware that a contribution of yours (something you write, say, or discuss in any IETF context) is covered by patents or patent applications, you need to disclose that fact. • You understand that meetings might be recorded, broadcast, and publicly archived. For further information, talk to a chair, ask an Area Director, or review the following: BCP 9 (on the Internet Standards Process) BCP 25 (on the Working Group processes) BCP 78 (on the IETF Trust) BCP 79 (on Intellectual Property Rights in the IETF)

3. Goal of this BOF Form a new WG immediately after this IETF Establish that… There is a problem to be solved (for the IETF) We have a critical mass of willing participants The scope of the problem is well defined/understood There is agreement on the set of deliverables The WG has a reasonable success probability

4. The Problem CoAP is moving towards mass deployment DTLS 1.2 is the chosen security mechanism Suitable range of security modes & ciphers This was exactly the right choice! However, DTLS has several drawbacks Handshake overhead is unnecessarily high DTLS handshake state-machine is complex (TCP + TLS) Not clear what sub-protocols, extensions and modes are needed No support for IP multicast, which CoAP is often used with What if we just do nothing? Proprietary, likely broken, security mechanisms will be invented Or worse, deployments without security, e.g. for multicast

5. The Scope The DICE working group would initially: Define a constrained DTLS profile For a specific use case in IoT Define DTLS record layer group communications With minimal record layer impact Explicitly out of scope: Changing DTLS in the profiling work Key management Specification of new cipher suites

6. Related Work Profiling Work Item Strawman http://tools.ietf.org/html/draft-keoh-dtls-profile-iot-00 Group Communication Work Item Strawman http://www.ietf.org/id/draft-keoh-dtls-multicast-security-00.txt Other Existing work http://www.ietf.org/id/draft-keoh-lwig-dtls-iot-01.txt http://www.ietf.org/id/draft-hartke-core-codtls-02.txt http://www.ietf.org/id/draft-tschofenig-lwig-tls-minimal-03.txt

7. Possible Future Work New transports for TLS, e.g. CoAP We need practical experience in the mean time Use of more efficient cipher suites, e.g. hash-only Requirements possibly from DICE, suite definition to be done in the TLS WG Revocation, access control list management But this probably belongs in its own WG

8. Work Item Presentations DTLS Profiling (10 min) - Hannes Tschofenig http://tools.ietf.org/html/draft-keoh-dtls-profile-iot-00 http://www.ietf.org/id/draft-keoh-lwig-dtls-iot-01.txt http://www.ietf.org/id/draft-hartke-core-codtls-02.txt http://www.ietf.org/id/draft-tschofenig-lwig-tls-minimal-03.txt Record Layer Group Communications (10 min) - Sandeep Kumar http://www.ietf.org/id/draft-keoh-dtls-multicast-security-00.txt

9. An Important Question a) Is this a topic the IETF should try to address? b) Is this a topic the IETF should not try to address? c) Do you not understand the problem well enough?

10. Proposed Charter INSERT HERE

11. Another Important Question a) Do you think this charter makes sense to propose? b) Do you think this charter does not make sense to propose? c) Do you not know enough to make a conclusion?

12. And Finally a) How many people are willing to edit, comment or implement documents?