DICE IETF-88 Minutes Scribes: Zach Shelby, Ari Keränen Profile - Zach, Klaus [draft-hartke-dice-profile-00] ---------------------------------------------------- Ekr: Avoid doing things TLS decided not to do. Ekr: Assymetric timer values needs evaluation, may need explicit DTLS support. Ekr: Might look at SHA based Ciphers. Carsten: How to align this with CoAP definited Ciphers for DTLS. Zach: We should absolutely align, however what we can do is define what DTLS extensions and settings to use with one of those Ciphers. Muliticast - Sandeep [draft-keoh-dice-multicast-security-01] ------------------------------------------------------------ Zach: Other key management mechanisms might already be able to handle this, for example OMA Lightweight bootstrap servers could do this with some simple object definitions. Mike St. John: What is the maximum bound on senders in a group? Sandeep: Much, much less than 64k Mike St. John: What about the client random? Sandeep: We throw that away, just using server. Kerry Lynn: How does this deal with intentional repeating of e.g. commands or retransmissions? Sandeep: We'll need a window size for detecting replay attacks. Don Sturek: Does the sender always have to listen for the epoch? Sandeep: No, the sender is generating that. Kevin: What if not all the listeners in the group are reachable at the same time? Sandeep: We are assuming all group memebers are on the same network. Mike St. John: may be hard to build hardware based on this; need to think all the bits Zach: anything we can do for the IDs to be unique, e.g., hashing? Sandeep: two byte ID, so only so much you can do Mike St. John: why only two byte ID? Should use something bigger? Erk: the ID is in the sequence number block Zach: talking about constrained devices; should rather go down on size than up Derrick: We are losing source authentication in this mechanism? Sandeep: That's correct, it is discussed in the draft. Chairs: This document has been around since before the DICE BOF and has no competing documents. Should we go ahead and take a hum regarding making this a WG document? Carsten: Yes, the right start. Ekr: We need to be clear what we are getting here. This is a limited mechanism re-using an existing mechanism. Mike St. John: feels like this document is written specifically for the cipher suites currently there. Need to make sure plug-in extensions are possible. Zach: true, need to make sure the users of this document are happy with it Kathy: crypto agility is important. We are getting requests for regional cipher suites Chairs: Hum if you agree to take this as a WG item: - About half the room. Hum if you disagree: - No hums. Chairs: Looks like we have consensus to take this forward, we'll also take the question to the list. DTLS practical issues - Klaus [draft-hartke-dice-practical-issues-00] --------------------------------------------------------------------- Zach: what do we need as output from dice? Short doc for TLS WG on what is needed for IoT usage? Ekr: yes, need to tell TLS WG what are the requirements Zach: there are things we can't do with profiling, those at TLS WG Sean T: if you do work on transport, need to talk with transport folks Ekr: key way of optimizing RTTs is to be optimistic on what server already knows Session Resumption - Rene Hummen [draft-hummen-dtls-extended-session-resumption-01] -------------------------------------------------- Ekr: client providing empty ticket assumes server wants to do session resumption? Easier to invent new extension for client side ticket? Zach: profiling work fixes some of the issues but more complex stuff needs to be done in TLS WG