Lightweight AKE for IoT (LAKE) IETF 105 22 July 2019, Monday 15:50-17:50, Van Horne Room Chairs: Stephen Farrell, Yoav Nir Minutes: Kathleen Moriarty & Christian Amsüss Jabber scribe: Francesca Palombini BoF description: https://trac.tools.ietf.org/bof/trac/wiki#LAKE Mailing list: https://www.ietf.org/mailman/listinfo/lake Jabber: lake@jabber.ietf.org Jabber logs: https://jabber.ietf.org/logs/lake/ Agenda: 10 - administrivia and history - chairs Note well reviewed & bluesheets Outcome is to provide a recommendation to the IESG Requirements are not final, this is a BoF Most in the room are familiar with the work 20 - requirements presentation - Göran Selander https://datatracker.ietf.org/doc/draft-selander-lake-reqs/ LAKE is about specifiying a lightweight AKE for OSCORE Not a new subject, has been discussed at legth since 2016 Compiled requirements and had discussion in a virtual interim OSCORE Background - communication security protocol for COAP, think of it as a REST Layer protecting payload, but not the messaging layer or binding to UDP. Proxies can change unprotected headers, good for IoT deployments. Initially designed for unicast and multicast at object level. Transport not covered, hence exposure of headers to proxies. For p2p to get Forward secrecy, requirement of new protocol Showed interest in OSCORE (slide available) OSCORE transport requirements: - needs master secret to derive the encryption keys, master secret should have forward secrecy, randomness, - arbitrarily short peer identifiers (as sent in all OSCORE exchanges) - COSE algorithms used by OSCORE - need symmetric and asymetric - additional credential requirements being discussed on list - raw public keys - short identifier that refers to the public key (clarification at mic from EKR) - identifier versus public key being carried are separate requirements - needs to be distinguished (Ben Kaduk attempting to clarify) - both are requirements from Goran - Crypto agility - built into infrastructure with long lifetimes, so necessary for OSCORE and AKE algorithms - Lightweight most important - low in resource consumption, start to end quick, power consumption, amount of code to produce (from SecDispatch discussion) - bytes on wire is straightforward if you look at message sizes - impacts time to complete and power consumption - wall clock time . - few RTTs as possible, 1-rtt mutually authenticated - at least 3 messages - power consumption depends on deployment circomstances - code complexity aspect based on reuse of a given OSCORE implementation - concrete measureable benchmarks needed (outcome of SecDispatch) - LWIG draft specifies the bechmarks - listed on slides. Benchmark 1: Energy consumption HIgh per byte energy consumption - slide with details on bechmark AKE few bytes as possible, message size matters Benchmark 2: LoRaWAN duty cycle back-off times High penalty for large messages, as they cause fragmentation AKE should fit in as few packages as possible High penalty for large messages, need for fragmentation Benchmark 3: Number of 6tisch message frames looking at 6TiSCH, similar to previous step-wise function; number of frames determines performance looking at join event when many devices connect to a central unit; long network connection times come from fragmentation number of frames needed for key exchange and make as few frames as possible is the goal factor of 2.6 between comparison of protocols Summary Slide read Questions: - Bob Moskowitz : Have you considered the # of operations of device - is there another requirement? - David Black: (3rd bullet on summary slide) What does "good amount of randomness" mean? Answer: entropy - not saying 128 bits, not on this level - any of those are fine - David Black: Is the PSK a strong secret? Goran: Yes - Hannes Tschofenig: Requirments miss privacy aspects, prior analysis had this as a gap and it's an important decision (not a clarifying question per chairs) - Renee Struik: Wasn't a clarifying question per chair Answer: people are deploying OSCORE without FS and they'd like to use public key soon 10 - edhoc quick intro - Göran Selander https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe/ - Skipping protocol details, how EDHOC matches the requirement, how it is a SIGMA implementation - Suitability for LAKE: Provides OSCORE identifiers - Supports negotiation of COSE algorithms, reuse helps keep footprint small - Small footprint b/c it reuses CBOR, COSE constructs - Constrained features - Security discussed at iterim - SIGMA-I, 2 crypto panel reviews, formal verification - summary: matches requirements, performs well in benchmarks - comparing preshared keys and raw public keys - b1 # of bytes - in certificate case, don't fit in single frames - comparison w/ SIGMA-I skeleton (bottom right on evaluation slide) that only sends the basic objects Questions: none (as the chairs insisted on clarifying questions only) 10 - ctls quick intro - Eric Rescorla https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ - providing another point in design space - how to leverage ongoing work on line of protocols - reap benefits from the line of work but also have compactness and patching - cutting fat or compression are two general approaches to reuse TLS - keep protocol general, but cut off unused parts - Certificate is the big thing - pile of extra features - length fields - could trim - fix length fields in some cases are larger than necessary (24bit never nearly exhausted) - values are implicit in some cases and could be made implicit - downgrade problems have creeped in - can remove downgradability - Can nail things down more and could do lots of compression - how to do mechanically? Treat wire transcript ? - Scott Fluhrer: Would that keep crypto agility: EKR: depending on how you do it in detail, yes - keep TLS 1.3 proofs valid -- straightforward on symbolic proofs - no one cares about encoding anyway - Example given in slides of ClientHello could have 32k cipher suites - not necessary - could cross off a lot of things to get a compressed representation - removes functionality, but may be ok with requirements - sliding scale of compression from simple struct to full generality - Richard Barnes: isomorphism point - interposed the stack (couldn't hear it all) - first implementations available, slides show numbers. Biggest chunk: "Finished" messages - first cut - need to demonstrate, not worth doing if you can't with 1.3 Questions: - Hannes: TLS is not compact in earlier slide, Hannes disagrees. TLS WG has worked through the year to compress it more over the years and doing this step by step with DTLS EKR: Efforts have been on the biggest thing, but more can be done - Yoav Nir: Numbers missing on preliminary results for what they were in TLS 1.3 Answer: no they're not here - Jim Schaad: [yes] Question not captured EKR: strongly suggest you can shrink them - Missed a few of the questions [?]: For first strategy proof is the same fo rthe second, should be pretty easy 20 - charter and usual BoF questions - chairs draft charter: https://mailarchive.ietf.org/arch/msg/secdispatch/zug9SCdn6prNdKvwX-ys3ZIg84s Charter discussion: - Hannes Tschofenig: Focus on OSCORE alone feels restrictive. IoTs are deployed using TLS and DTLS. EKR's work on constraining that would be fine for them w/o having to worry about OSCORE. Göran's presentations mixed "is specified" and "is deployed", and OSCORE is not as widely deployed. Would like to have broader focus, not only on OSCORE. - Göran responding: This discussion is two parallel discussions. What's being done on TLS to make it more optimal is excellent. HAppy to use that for where TLS is used. But not providing the most optimal for the most constrained settings. Two separate questions: How do we solve the very constrained settings with current OSCORE w/o key exchange? The other is: How do we make TLS in itself more optimal? Two good questions, both to be discussed, should not interfere. - PHB: Concerned on list that we are only going to look at existing key exchange protocols, but introduce new requirements. Don't like that they have to start with something that exists and it goes into a rat hole. Looks like a new key exchange and not complete reuse, he would go to CTLS for branding. If he wants to use DTLS he can find it in a toolkit, will probably get ctls for free. Naming matters. - Ben Kaduk: in A bOF, not WG. Agreement that there's a problem that needs solving and people willing to work on and understand scope of problem and what the WG will work on and don't have to work on it right here. Think of higher level questions - do we want to solve it here at the IETF. DO we understand scope of the problem? Bob asked a completely different requirement, so did PHB. - [Benjaminn Damm]: Things heard but not true: got millions of meters that do not use TLS, probably some proprietary. If had OSCORE and EDHOC would have used it. (clarifying: Not using TLS b/c too heavyweight?) yes. For us, every bit on "wire" (air) costs money. 20 more bytes in handshake cost us money. more collisions in air, size really matters. Also, if isomorphism cTLS-TLS there could be one TLS-OSCORE (comments: no, it's not, we looked at it). - Carsten Bormann: Like Hannes' comment b/c CoAP has a security scheme using DTLS, want better DTLS. In tasks like this, think of unintended consequences. Would like to talk about intended consequences. Would be ctls have happened without this discussion (audience: NO). One intended consequence to keep mild pressure up for cTLS to happen. cTLS already has a home. EDHOC does not have a home and how do create one? Important consequence - EKR: Doesn't think what we are discussing - don't see EDHOC written here (answering Carsten). Agree partially with Hannes and Göran; would be sad if it only worked with OSCORE. . Designing these things is hard. The more input, the better. more applicability and generality the better - Cullen Jennings: Anytime we do a protocols, more specific between new protocol or generalizing another. Perfectly happy ? Other comment: shocked to see how awful job on TLS before, hope to get it much smaller really soon. - Yoav Nir: Don't decide on specialization in BoF - Hannes Tschofenig: ad "is there problem to be solved?" my company works for mbedTLS and deploys IoT in devices. DOn't have the same problems as other companies, can run secure IoT over those and other networks today. Primary reason: Can cut down, but try to look on bigger picture, whole lifetime of device, what at beginning (onboarding), connection, afterwards? Think 10 years lifetime from coin battery. Many problems are actually elsewhere (like large certificate). Firmware update is less sexy, but important but that's where the battery drains, not in key exchange protocol (b/c session resumption etc). That's why we don't see those problems. Also ad ITON: see possible improvements in design that avoid those issues. Happy to see, as Cullen said, Working to shrink TLS, happy to see it. Would have loved Göran & co to have come to TLS and help me out with convincing TLS to help me in shrinking. - Ivaylo: Have OSCORE implementation, interested in LPWAN, very constrained. Important to have small implementations and need to reuse components, that helps a lot. Therefore interested in this. - Malisa Vucinic: USing OSCORE in adopted WG document in 6TiSCH for 3 years now. Asked for AKE for OSCORE Satisfying the requirements as Göran presented. Good we have discussion today and opposing solutions. Problem of designing an AKE for OSCORE - Jari Arko: Work should go ahead. Shouldn't preclude work on cTLS and DTLS. Generalize my comment: Sometimes in IETF focused on one thing too much to the detriment of the Internet, we are starting to see that impact. Sometimes need something else. to have end-to-end security on relays too with transport. - Kathleen Moriarty: Happy to see work go forward, similar to Jari, like having an object level encryption protection across relays coupled with a transport. See no conflict of having both ctls and OSCORE & EDHOC - MCR: implemented 6TiSCH, BRSKI over DTLS. Can talk about threading problems etc / but are implementation issues. Like Philip said: can download standard library with advantage with existing system, but disadvanage of having to cope w/ existing system. Willing to rewrite it from scratch like Hannes' company did? CoAP implementers tend to process one request per thread in thread pool. Doesn't work well w/ security above and below application, but particularly you are forced to do threading below is forced with currentlibrary. [...] What we try to do is key OSCORE. Don't want to run CoAP over DTLS, want to key OSCORE and let CoAP run. That's where transport agility comes from, across layers[?]. It's across different transport mechanisms (not layers). CoAP/OSCORE can be transported across many things other than UDP, and if we do the AKE at the CoAP layer (rather than outside/around as DTLS does), then it is easier to get the properties we want. - Justin Richer: not picking side, followed from distance. Many ppl say it's easy b/c we did similar thing and if we change this and that ... but all I want to do is encourage WG to approach such claims with appropriate scepticism, b/c when altering existing systems to new use cases, they're being twisted in hard-to-predict ways, and details can kill you there. whoever claims to jsut have changed everything and it still works fine on our bespoke box, that may not scale well. - Hannes coming back to MCR: Sounds like easy to just re-implement those new protocols and then be done with it. But had ppl working on it 10y long, and Embeeded space is hard. Have to integrate into IDEs. time consuming. Who writes new embedded security stack for EDHOC, maintain it, with all features around that for next 10 years? Looks like extensions coming out of TLS is difficult. So many contributors for TLS, it's difficult. - Richard Barnes: Clarifying: cTLS doesn't makes sense as a TLS work item. Questions of trade-offs between rigidity and size and where you want to be. Structure depends on the ebnvironment where it is going to be used. - Dave Wheeler: heard "presentation seems like we take somethign and tweak it a little to make it completely different and do it quick without any RFCs". Scares me, maybe I misunderstand. Seems we need different keying protocol, and should address that appropriately w/ right amount of resources coming in. - Stephen Farrell: Idea here is to document and agree on requirements, don't make that an RFC, but the protocol will be. - PHB: needs to be a separate WG, not TLS. Hope to reuse proofs, but acedemics are free with infite numbers of grad students. - Tero Kivenen: Header compressed TLS example - use1.3 frame and compress it sending with minimal stuff needed, and not modify TLS. - EKR: Academics are not free. Was enormous amount of work on TLS. It's difficult to get ppl to do things, and they do hard work. - Carsten Bormann: on cTLS. Work that will cTLS needs resources from TLS WG, and needs them more urgently than resources from constrained ppl. Will have requirements document, and they can inplement against that. Hard part is touching TLS and not breaking it. Have draft from 2013 from student that described DTLS compression. The way it's designed, there are finish messages that work on what was on wire, and then have to reconstruct. So thinking about finish msg is probably the most important thing to take home. - Richard Barnes: Two sides of the relationship - things you are not familiar with seem the hardest to both sides. How does this AKE - what integration surface is needed? Would be good to get general shape of protocol into the requirements. - Carsten: Also whole application layer TLS usage issue that comes in, which we have to address in time. On why IoT stuff is almost trivial in comparison: Security must work. If 3 bytes too large, that's not a disaster. Error in security is. - Riad Wahby: Impicit shared notion of all the costs. Useful to have multiple models. Usefult to specify assumption without cost of certain things. If you just need size, it may be reasonable to compress TLS and be done, if that's not what you mean, document it. - Hannes: bytes on wire are easy to put together on paper. ad [?]tls: put together draft that was written some time ago, kind of makes sense here. - Ben Kaduk: BoF Questions?? Really wants to hear interest. Excited to see discussion on scope and requireemnts that were not mentioned. # of AKEs? How to integrate OSCORE, TLS won't be able to do. How tightly couled requireemnts with use cases? How flexible we want to be with use cases? Assumptions on cost - write them down! - Goran: Starting with assumptions and costs, basically been doing in SecDispatch with benchmarks and not easy to get exactly right. Not easy to produce an excellent requirements document that guides to a solution. Ad solution space: Important that optimal solution probably isn't cTLS (not as lightweight as what I have shown). At some point pick between isomorphism of TLS or optimal solution, so ppl don't expect that it will be both. Already did good job in showing the isomorphism. Don't think you'll get down to levels that are optimal with a widdling of TLS. - Ben Kaduk: have some text in draft charter about at most one?? [...]. - Dave Thaler: ad Ben's repeated questions. To most: yes. Ad scope: All text on screen under "program of work" and under "goals" talks constrained environments, but not OSCORE and object level security. But requirements are about OSCORE. Is one too broad, or the other to narrow? Is it "solve for OSCORE and if it works for others it's great", or [?] Problem defined well, but maybe scope of work needs to be redefined - EKR: thinks it should be flipped. - Hannes: another facet to problem statement. Would like to see something about object security. OSCORE is not object level security. In @ we describe how to derive keys for COSE, and that's object level security. For that we'll need key management protocol. Someone also said OSCORE is protocol agnostic. It's over-advertisement when what comes in and out is a REST protocol. Talked about ITRON case, it's probably not restful. Most MQTT users ... not RESTful protocol. Just about what protocol agnostic means. - David Black: Survived TCPInc - advice: it'd be irresponsible of IESG to start working group without picking the starting protocol. Saying IESG should make tough decisions? no. But hard decisions need to be made. - Yoav: If requiremnts not final, how do we decide between them. - Alissa Cooper: @@@ time to take decision ? - David: Hoping not to spend 2y on charter. Limit to amount of BoFs you can have. Want it to serve as a forcing function - Alissa: So this process will time out and that's a better thing than starting a WG just to stall w/o a decision? - David doesn't think it's a good use of resources to start without a decion. - Carsten: did ISO standardizaion. They use requirements a lot. "Requirements engineering" is engineering requirements such that solution comes out as chosen. Work on requirements is tainted by this. Shouldn't spend a lot of time honing requirements Having an idea about reqments is good, but should not spend much time there. - Yoav: By time requirments are finished, not off the table, if both meet it, could decide by coin toss. - Cullen: Bad idea. Decision of CODEC to use would not have come to a good decision after 4 years and would never have chartered WebRTC had that not happened. WebRTC had a more difficult decision on video codec, and would never have managed w/o roughly 4 years of repeated discussions in WG meetings. Would never have chartered if we knew we had to make decision before [?] - Goran: we're spending 4 years and many applications not using anything, don't have FS for OSCORE, not a good result. Not the same solutions, have difficulty seeing that and don't see the issue with multiple solutions. - Phillip: push back on "picking one is necessary to speed things up". If you pick a winner and then start changing it, it takes forever At one point starting from house and remodeling seems good, but after some time built house twice. Seen in other WGs: "we must do it now" -- 5y later still at it, WG failed b/c chose wrong protocol to try to do it fast. Shortcuts aren't good. - EKR: 13' to go, can't realistically arive [?]. Focus on progress: Options: go home; schedule another meeting on starting point; [?] - Benjamin: There is an audience problem. CoAP isn't HTTP. Why came up w/ CoAP when HTTP could do everything that CoAP does? My position: very different audiences. Embedded audience cares about very differnt things and they are at odds - COAP/HTTP. They serve a different audience. When do we embrace that split with AKEs? - Dave Thaler: Will have question of "do ppl understand the problem". Ppl understand, but there's two problems, the narrow problem of OSCORE and the wide of the milestones. Would be good for everyone if they have well-defined problem, but it's different ones for different people. Two communities in this room. When questions on next slide (Big Questions) asked, please phrase them so I know how to answer. Two views of what the problem is. - Yoav: We are here to solve that as the OSCORE problem. Big questions being rephrased to make progress by Dave Thaler - Dave Thaler: suggesting questions. usual BoF questions: https://tools.ietf.org/html/rfc5434#section-1 * Do you understand the issues? strong yes hum on question, no on negative question * Is OSCORE Key exchange a ('the narrow') problem that needs being solved? strong on yes, none on negative question * Is broader constrained scenario a problem that needs solving? strong on yes, low on no - MCR: explaining his no on last question on demand: my experience from Hannes' environments: if enough code space and other power to run TLS, it doesn't matter. Kind of a step function. If you can run a bit, you can probably do a bit more. Hannes' "you don't AKE often" is probably true. If running MQTT, security overhead is not what's killing your network - Hannes will post paper on crypto libraries - crypto algorithms are problem and not the TLS stack. Here is the paper Hannes mentioned: Secure Firmware Updates for Constrained IoT Devices Using Open Standards: A Reality Check” https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8725488 - ?: Do they need TLS? There should be a way to do it in OSCORE that doesn't require extra protocol. * "Is IETF the right place?" Strong yes on IETF is the place to do the work. * Willing to work on documents - comment, review, etc. - 15-17 hands for OSCORE - 10-11 hands for the general case - Few overlapping.