Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports
Richard Barnes ; wrote: >This is the part that worries me. It would be helpful to be very crisp >about what assumptions are being changed here, and why it's OK for them to >be changed. Especially given that the Bruni et al. paper seems to have >found flaws. As explained in Stanislav's CFRG crypto review: "The concerns of [1] (namely, section 2.3 of [1]) has been addressed." https://mailarchive.ietf.org/arch/msg/cfrg/6WN2C2RYGTIAInE2jIUco6L9pO8 As the concerns were about the ability of end users to understand the security properties of early application data, I think similar concerns could be made regarding (D)TLS 1.3. Regarding differences between EDHOC and TLS 1.3, EDHOC is closer to the deeply analyzed SIGMA-I protocol. Many of the additions TLS 1.3 do to SIGMA-I are as far as I know done to support additional features: - Nonces enable TLS 1.3 to work with 0-RTT data, to support PSK mode without PFS, to work with static Diffie-Hellman keys in older versions of TLS, and to look like TLS to middleboxes and applications that expect TLS to look a certain way. - A MAC in TLS flight #1 enables 0-RTT data. - The split into handshake and record layer means that TLS flight #2 and #3 contain two MACs Most of the additions EDHOC made to SIGMA-I are summarized in Stanislav's CFRG review: "The EDHOC protocol looks well-designed. Particularly, the reviewer would like to mention such solutions as CRED_x under signature, which is good to prevent DSKS-type attacks; a downgrade protection based on sending both a list of supported suites and a selected one with aad2 and aad3 messages being hashes from all previous messages (binding the communications together); KCI-attacks are inapplicable due to SIGMA-like ephemeral keys usage." (Similar additions are done in TLS 1.3 as well, but EDHOC aims for very simple solutions that keep the code and memory complexity as low as possible). - Other differences are mainly in encoding and different design requirements, TLS supports a large number of additional extensions and options and it also has to interop with older versions. DTLS adds a lot of transport related things that EDHOC relies on CoAP for. TLS was designed with web servers as the main use case. EDHOC is not trying to replace TLS, I love TLS 1.3, and I advise Ericsson products and SDOs to use TLS as much as possible. But the TLS handshake was certainly not designed with constrained IoT as the main use case. We are trying to bring SIGMA-I level end-to-end protection to constrained IoT systems where TLS is impractical. Cheers, John ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports
Hi Valery, On 2019-02-19, 19:02, "Valery Smyslov" wrote: > When done over CoAP, the message would be sent with CONfirmable, so it > would be ACK'ed. I would make the first message CONfirmable too. > > That makes it much like IKEv2 is, where all messages are ACKed and the > initiator is responsible for all retransmits. Sure, there must be no problems with COAP or other reliable transport. > If someone wants to run EDHOC over another transport, then they would > need to take this into account. That was my point. Thanks, we will include a consideration about this. Best regards Göran ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports
Hi Michael, > When done over CoAP, the message would be sent with CONfirmable, so it > would be ACK'ed. I would make the first message CONfirmable too. > > That makes it much like IKEv2 is, where all messages are ACKed and the > initiator is responsible for all retransmits. Sure, there must be no problems with COAP or other reliable transport. > If someone wants to run EDHOC over another transport, then they would > need to take this into account. That was my point. Regards, Valery. > > So, unless you rely on a reliable transport that preserves packets ordering, > > having odd number of messages significantly complicates > implementations. > > CoAP is reliable, and it does preserve packet ordering if asked to. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports
Valery Smyslov wrote: >> Current version of EDHOC is 3-pass to allow traffic data after one round trip, >> which reduces latency in many applications. >> A 4-pass version has also been discussed: >> https://mailarchive.ietf.org/arch/msg/ace/ZDHYEhvI0PenU6nGrhGlULIz0oQ >> >> When EDHOC is used as key exchange for OSCORE, and also in other settings, >> EDHOC will commonly run on top of CoAP. For example, in 6tisch the join >> protocol relies on CoAP proxy functionality. CoAP is defined for reliable >> transport (RFC 8323) as well as UDP (RFC 7252), the latter handles >> retransmissions by client and server. An example of using EDHOC with CoAP is >> given in appendix D.1: >> https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-11#appendix-D.1 >> >> It sounds like we should add some considerations for the setting you outline. >> Do you have an example or pointer explaining the specific problem in more >> detail? > In the current EDHOC draft the initiators sends the last (third) message of AKE and then > immediately starts sending encrypted data (note, that he has almost > always something to send, When done over CoAP, the message would be sent with CONfirmable, so it would be ACK'ed. I would make the first message CONfirmable too. That makes it much like IKEv2 is, where all messages are ACKed and the initiator is responsible for all retransmits. If someone wants to run EDHOC over another transport, then they would need to take this into account. > So, unless you rely on a reliable transport that preserves packets ordering, > having odd number of messages significantly complicates implementations. CoAP is reliable, and it does preserve packet ordering if asked to. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports
Hi Göran, > Current version of EDHOC is 3-pass to allow traffic data after one round trip, > which reduces latency in many applications. > A 4-pass version has also been discussed: > https://mailarchive.ietf.org/arch/msg/ace/ZDHYEhvI0PenU6nGrhGlULIz0oQ > > When EDHOC is used as key exchange for OSCORE, and also in other settings, > EDHOC will commonly run on top of CoAP. For example, in 6tisch the join > protocol relies on CoAP proxy functionality. CoAP is defined for reliable > transport (RFC 8323) as well as UDP (RFC 7252), the latter handles > retransmissions by client and server. An example of using EDHOC with CoAP is > given in appendix D.1: > https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-11#appendix-D.1 > > It sounds like we should add some considerations for the setting you outline. > Do you have an example or pointer explaining the specific problem in more > detail? In the current EDHOC draft the initiators sends the last (third) message of AKE and then immediately starts sending encrypted data (note, that he has almost always something to send, because it is he who initiates secure connection with responder). If this third message is lost or the packets are reordered, then the responder will start receiving encrypted data from the peer he hasn't authenticated yet. The responder in this case has two options - either discard incoming encrypted data or buffer it in hope that the last EDHOC message will come shortly. Both alternatives are bad - either it impacts application protocol or opens surface for DoS attack. Note, that from the initiator's point of view everything is fine, the protocol has completed successfully, so in general the problem cannot be solved by sending retransmissions by initiator, instead, the responder must become an active retransmitter in this case and re-send the second message to nudge the initiator to re-send the third. This was discussed in the ipsecme WG when IKEv2 was being designed (back to 2003-2005). So, unless you rely on a reliable transport that preserves packets ordering, having odd number of messages significantly complicates implementations. Note also, that lacking the fourth message there is no way for the responder to report any authentication error back to the initiator... Regards, Valery. > Thanks, > Göran > ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports
Hi Valery, On 2019-02-18, 08:07, "Valery Smyslov" wrote: Hi, > Richard Barnes wrote: > > Finally, to be totally honest, I find the EDHOC spec pretty inscrutable. A > > little more prose to explain what's going on would go a long way toward > > helping this discussion be productive. > > Sure. > Find a WG to adopt it, and we can make the text beautiful. > The packets are all there, and the references pretty much explain all the crypto. > This stuff is not any newer than IKEv2. I have only a quick look over the draft, but one thing strikes me - the protocol is claimed not to bound to a particular transport (so I assume that implementing it on top of pure UDP is fine), and it has an odd number of messages. That's OK from cryptographic point of view, but it's a headache for implementations if the transport protocol is unreliable, since in this case retransmissions must be sent by both parties. We learned this lesson from IKEv1 (Aggressive and Quick modes) and in IKEv2 the number of messages in any exchange is always even, that simplifies implementations and makes protocol more reliable. Of course if only reliable transports are considered, then this doesn't matter. Current version of EDHOC is 3-pass to allow traffic data after one round trip, which reduces latency in many applications. A 4-pass version has also been discussed: https://mailarchive.ietf.org/arch/msg/ace/ZDHYEhvI0PenU6nGrhGlULIz0oQ When EDHOC is used as key exchange for OSCORE, and also in other settings, EDHOC will commonly run on top of CoAP. For example, in 6tisch the join protocol relies on CoAP proxy functionality. CoAP is defined for reliable transport (RFC 8323) as well as UDP (RFC 7252), the latter handles retransmissions by client and server. An example of using EDHOC with CoAP is given in appendix D.1: https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-11#appendix-D.1 It sounds like we should add some considerations for the setting you outline. Do you have an example or pointer explaining the specific problem in more detail? Thanks, Göran ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports
Hi Michael, On 2019-02-18, 02:35, "Ace on behalf of Michael Richardson" wrote: Richard Barnes wrote: > Finally, to be totally honest, I find the EDHOC spec pretty inscrutable. A > little more prose to explain what's going on would go a long way toward > helping this discussion be productive. Sure. Find a WG to adopt it, and we can make the text beautiful. I believe this is what the SecDispatch chairs are considering. I know of others sharing your impatience too. The packets are all there, and the references pretty much explain all the crypto. This stuff is not any newer than IKEv2. EDHOC is neither TLS 1.3 nor IKEv2. The similarity with other AKEs comes from being based on same SIGMA protocol. Current version of EDHOC is based on Sigma-I, but the Sigma-R version discussed in a parallel thread is similar to IKEv2: https://mailarchive.ietf.org/arch/msg/ace/ZDHYEhvI0PenU6nGrhGlULIz0oQ Göran ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports
Hi Richard, From: Richard Barnes Date: Friday, 15 February 2019 at 17:19 To: Göran Selander Cc: "secdispa...@ietf.org" , "ace@ietf.org" Subject: Re: [Secdispatch] FW: [secdir] EDHOC and Transports On Fri, Feb 15, 2019 at 7:13 AM Göran Selander mailto:goran.selan...@ericsson.com>> wrote: Hi Richard, Thanks, that is a fair question to ask on behalf of those who are new to the subject. The short answer is: Yes, we have counted every byte of the TLS handshake and, no, we don’t think it is possible to support the same radio technologies as EDHOC do, unless you change some assumption which impacts the security analysis of TLS. This is the part that worries me. It would be helpful to be very crisp about what assumptions are being changed here, and why it's OK for them to be changed. Especially given that the Bruni et al. paper seems to have found flaws. Your point about CBOR isn't relevant here. Re-encoding is fine; it's changing the AKE that necessitates a whole bunch of new analysis. Perhaps I was unclear: We are not proposing any changes to (D)TLS 1.3. We believe that making (D)TLS 1.3 AKE fit into small frames requires changing some assumption of the protocol which, as you say, would necessitate a new analysis of TLS. The point about reencoding is about inefficiency or incompatibility, which are both relevant for the overall discussion, but not about security. The paper you mention analyzed version -08 of EDHOC and, essentially, the expected security properties hold. All comments from this analysis are addressed in the updated version of the protocol. Section 4 of the paper describes the security properties. Their main concern was related to the application data sent by party V in message #2 (APP_2 in -08) being encrypted, which may mislead application developers that it is protected for the intended party U, but party U is not authenticated at the time of sending message #2. Later versions of the draft emphasize how to handle data which is not protected (see Section 8.4 in -11) and the APP_2 message field is renamed UAD_2 (Unprotected Application Data). Finally, to be totally honest, I find the EDHOC spec pretty inscrutable. A little more prose to explain what's going on would go a long way toward helping this discussion be productive. What part of the draft did you find difficult to understand? Göran ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports
Richard Barnes wrote: > Finally, to be totally honest, I find the EDHOC spec pretty inscrutable. A > little more prose to explain what's going on would go a long way toward > helping this discussion be productive. Sure. Find a WG to adopt it, and we can make the text beautiful. The packets are all there, and the references pretty much explain all the crypto. This stuff is not any newer than IKEv2. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports
Hi Richard, Thanks, that is a fair question to ask on behalf of those who are new to the subject. The short answer is: Yes, we have counted every byte of the TLS handshake and, no, we don’t think it is possible to support the same radio technologies as EDHOC do, unless you change some assumption which impacts the security analysis of TLS. The longer answer is embedded in the previous mails, for convenience I reiterate some of the items. 1. A property like energy consumption is not binary, but the smaller the message overhead the better, primarily because it makes the messages fit into smaller frame sizes but also because of per byte power consumption which is noticeable in some radio technologies. Fitting into frame size means avoiding a step up in power consumption due to transmission overhead not related to the payload, and also having fewer packets that may be corrupted and result in retransmission with additional power consumption. For example, LoRaWAN has a packet size for DR0-2 (51 bytes, in practice a few bytes less), in which we can fit all messages with EDHOC PSK ECHDE. While EDHOC messages are small, we certainly would welcome an even smaller handshake with the same functionality to better handle other radio technologies and fragmentation schemes with even smaller frame sizes, but we’re not interested in something less optimal. 1. As Hannes and I agree, this is not only about message overhead. Memory and code size in a device are also important, specifically what is added on top of CoAP and OSCORE, which are already implemented in the targeted device. This is the reason why EDHOC builds on CBOR and certain COSE objects. Downsizing an existing protocol still means new code is needed, as using a subset of the protocol does not decrease the size of existing implementations. Furthermore, changing encoding may lead to incompatible handshake message formats: Over what are signatures made; the original encoding or the compact? If the original, then the constrained device must re-encode in order to verify the signature, which adds even more to memory and flash. If the signature is on the compact encoding, then it is not backwards compatible with since legacy implementations cannot verify. In either case a major point with profiling is lost. 1. As a final point for people entering the discussion late, this is not a draft coming out of the blue; there is a history to consider. After the first in-room rough consensus for adoption in ACE at IETF 98 https://datatracker.ietf.org/doc/minutes-98-ace/ the progress of EDHOC went into offline mode, during which the authors were tasked to work on formal verification (see below) and make comparison with TLS handshake. We showed that there are significant differences in overhead: https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-11#appendix-E.4 We have also shown that these differences have an impact on energy consumption and latency, and on what radio technologies can be supported (see below in this mail). These properties are the results of having constrained IoT as an explicit target for the protocol. As this was not the case for the TLS handshake it should not come as a surprise that it may be difficult to retrofit without changing some basic assumptions used in the security analysis, like removing the nonces. We are happy to deploy the result of an optimized DTLS but we don’t think it is fair that such work should hold up the progress of this draft any longer. As for the formal verification, we were fortunate that the IT University of Copenhagen volunteered and has now proved properties like injective agreement, secrecy and forward secrecy to be discussed more in the interim meeting. An analysis of a previous version of the draft is here: https://www.springerprofessional.de/en/formal-verification-of-ephemeral-diffie-hellman-over-cose-edhoc/16284348 (a link to the paper will be available in the agenda) We are aware of that more security analysis is needed, but would like to think that the properties listed above are good enough for adoption. That is also one factor that would significantly increase the motivation for people to make further analysis of the security of EDHOC. Göran From: Richard Barnes Date: Thursday, 14 February 2019 at 16:42 To: Göran Selander Cc: Hannes Tschofenig , "secdispa...@ietf.org" , "ace@ietf.org" Subject: Re: [Secdispatch] FW: [secdir] EDHOC and Transports Göran: When these metrics talk about DTLS 1.3, do they mean that protocol directly, unmodified? One alternative approach people have had in mind is the idea of re-encoding / profiling down DTLS so that although it is syntactically different and maybe has fewer options, it encodes the same underlying AKE. Has that path has been explored? On the one hand, if it succeeds in slimming down DTLS to an acceptable point, it would obviate the need for a whole bunch of new analysis. On the other
Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports
Göran: When these metrics talk about DTLS 1.3, do they mean that protocol directly, unmodified? One alternative approach people have had in mind is the idea of re-encoding / profiling down DTLS so that although it is syntactically different and maybe has fewer options, it encodes the same underlying AKE. Has that path has been explored? On the one hand, if it succeeds in slimming down DTLS to an acceptable point, it would obviate the need for a whole bunch of new analysis. On the other hand, if it fails, then it should highlight the specific things EDHOC has done differently, so that analysis can be focused on those things. Thanks, --Richard On Mon, Feb 4, 2019 at 10:41 AM Göran Selander wrote: > Hi Hannes, secdispatch, and ace, > > (It seems Hannes original mail only went to secdispatch.) > > Apologies for a long mail, and late response. I had to ask some people for > help with calculations, see end of this mail. > > On 2019-01-25, 15:15, "Secdispatch on behalf of Hannes Tschofenig" < > secdispatch-boun...@ietf.org on behalf of hannes.tschofe...@arm.com> > wrote: > > Fwd to SecDispatch since it was only posted on the SecDir list > > -Original Message- > From: Hannes Tschofenig > Sent: Freitag, 25. Januar 2019 14:07 > To: Hannes Tschofenig ; Jim Schaad < > i...@augustcellars.com>; sec...@ietf.org > Subject: RE: [secdir] EDHOC and Transports > > A minor follow-up: I mentioned that I am aware of a company using the > energy scavenging devices and it turns out that this information is > actually public and there is even a short video on YouTube. The company we > worked with is called Alphatronics and here is the video: > https://www.youtube.com/watch?v=JHpJV_CPYb4 > > As you can hear in the video we have been using our Mbed OS together > with our device management solution (LwM2M with DTLS and CoAP) for these > types of devices. > > [GS] Nice application of LwM2M. The showcased device didn't seem very > constrained though, ARM Cortex M4? > > -Original Message- > From: secdir On Behalf Of Hannes Tschofenig > Sent: Freitag, 25. Januar 2019 13:52 > To: Jim Schaad ; sec...@ietf.org > Subject: Re: [secdir] EDHOC and Transports > > >[Hannes] what we are doing here is making an optimization. For some > (unknown reason) we have focused our attention to the over-the-wire > transmission overhead (not code size, RAM utilization, or developer > usability*). > > [GS] Exactly my point, it is not enough with reducing transmission > overhead. We should also look at additional memory, flash, and > configuration effort. These parameters are of course implementation > dependent but can to some extent be inferred by bulk of specification and > what pre-existing code can be reused. > >[Hannes] We are doing this optimization mostly based on information > about what other people tell us rather than based on our experience. The > problem is that we have too few people with hands-on knowledge and/or > deployment experience and if they have that experience they may not like to > talk about it. So, we are stepping around in the dark and mostly perceived > problems. > > [GS] I don't think this rhetoric is very helpful. Who are "us"? The > co-workers you quote below, are they "us" or the "other people"? The people > active in 6tisch, lpwan or 6lo who are supporting the work on an optimized > key exchange, are they "us" or the "other people"? > > >[Hannes] Having said that I would like to provide a few remarks to > your list below: > > [Jim] 1. Low-power devices that either are battery based or scavenge > power, these devices pay a power penalty for every byte of data sent and > thus have a desire for the smallest messages possible. > > [Hannes] Low power is a very complex topic since it is a system issue > and boiling it down to the transmission overhead of every byte is an > oversimplification. You are making certain assumptions of how power > consumption of radio technologies work, which will be hard to verify. I > have been working on power measurements recently (but only focused on power > measurements of crypto, see > https://community.arm.com/arm-research/b/articles/posts/testing-crypto-performance-and-power-consumption). > > > [GS] These kind of power measurements of crypto are part of the > explanation for why transmission overhead is important to reduce. > Optimizations and hardware support make the crypto contribution to power > consumption possible to handle, so that there is no reason to deviate from > the use of current best practice crypto in security protocols even for > constrained devices. The energy cost for transmission, however, is a > strongly coupled to the laws of physics which sets a limit for how much > they can be optimized. > > [Hannes] I doubt that many people on this list nor in the IETF have a lot > of experience in this field to use this as a basic for an optimization. > > [GS] There are people in 6tisch,
Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports
Hi Göran, I will obviously not be able to convince you to change your research strategy. So, I will not even try. Anyway, thanks for the performance measurements your co-workers created in the Excel sheets. I will take a closer look at them. One item worthwhile to respond is the choice of the MCU. You wrote: [GS] Nice application of LwM2M. The showcased device didn't seem very constrained though, ARM Cortex M4? The Cortex M4 offers a larger instruction set, including DSP/SIMD capabilities, compared to something like the M0+. You can see the differences at https://en.wikipedia.org/wiki/ARM_Cortex-M In this blog post, see https://community.arm.com/processors/b/blog/posts/armv6-m-vs-armv7-m---unpacking-the-microcontrollers, Chris Shore shows the difference in the instruction set graphically. Using these extra instructions code can be executed faster. This faster execution time is already ensured by compilers but if you additionally use hand-crafted Assembly code then you will get an extra performance improvement. My co-workers from the Mbed TLS team have written hand-crafted Assembly to speed up bignum computations, see https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/bn_mul.h#L645 https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/bn_mul.h#L582 Executing code faster gives the device the ability to enter a low power state quicker. Additionally, if you use sensor fusion then having floating point support in hardware will make your life easier (and the code faster). Ciao Hannes -Original Message- From: Göran Selander Sent: Montag, 4. Februar 2019 18:41 To: Hannes Tschofenig ; secdispa...@ietf.org; ace@ietf.org Subject: Re: [Secdispatch] FW: [secdir] EDHOC and Transports Hi Hannes, secdispatch, and ace, (It seems Hannes original mail only went to secdispatch.) Apologies for a long mail, and late response. I had to ask some people for help with calculations, see end of this mail. On 2019-01-25, 15:15, "Secdispatch on behalf of Hannes Tschofenig" wrote: Fwd to SecDispatch since it was only posted on the SecDir list -Original Message- From: Hannes Tschofenig Sent: Freitag, 25. Januar 2019 14:07 To: Hannes Tschofenig ; Jim Schaad ; sec...@ietf.org Subject: RE: [secdir] EDHOC and Transports A minor follow-up: I mentioned that I am aware of a company using the energy scavenging devices and it turns out that this information is actually public and there is even a short video on YouTube. The company we worked with is called Alphatronics and here is the video: https://www.youtube.com/watch?v=JHpJV_CPYb4 As you can hear in the video we have been using our Mbed OS together with our device management solution (LwM2M with DTLS and CoAP) for these types of devices. [GS] Nice application of LwM2M. The showcased device didn't seem very constrained though, ARM Cortex M4? -Original Message- From: secdir On Behalf Of Hannes Tschofenig Sent: Freitag, 25. Januar 2019 13:52 To: Jim Schaad ; sec...@ietf.org Subject: Re: [secdir] EDHOC and Transports [Hannes] what we are doing here is making an optimization. For some (unknown reason) we have focused our attention to the over-the-wire transmission overhead (not code size, RAM utilization, or developer usability*). [GS] Exactly my point, it is not enough with reducing transmission overhead. We should also look at additional memory, flash, and configuration effort. These parameters are of course implementation dependent but can to some extent be inferred by bulk of specification and what pre-existing code can be reused. [Hannes] We are doing this optimization mostly based on information about what other people tell us rather than based on our experience. The problem is that we have too few people with hands-on knowledge and/or deployment experience and if they have that experience they may not like to talk about it. So, we are stepping around in the dark and mostly perceived problems. [GS] I don't think this rhetoric is very helpful. Who are "us"? The co-workers you quote below, are they "us" or the "other people"? The people active in 6tisch, lpwan or 6lo who are supporting the work on an optimized key exchange, are they "us" or the "other people"? [Hannes] Having said that I would like to provide a few remarks to your list below: [Jim] 1. Low-power devices that either are battery based or scavenge power, these devices pay a power penalty for every byte of data sent and thus have a desire for the smallest messages possible. [Hannes] Low power is a very complex topic since it is a system issue and boiling it down to the transmission overhead of every byte is an oversimplification. You are making certain assumptions of how power consumption of radio technologies work, which will be hard to verify. I have been working on power measurements recently (but only focused on power
Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports
Hi Hannes, secdispatch, and ace, (It seems Hannes original mail only went to secdispatch.) Apologies for a long mail, and late response. I had to ask some people for help with calculations, see end of this mail. On 2019-01-25, 15:15, "Secdispatch on behalf of Hannes Tschofenig" wrote: Fwd to SecDispatch since it was only posted on the SecDir list -Original Message- From: Hannes Tschofenig Sent: Freitag, 25. Januar 2019 14:07 To: Hannes Tschofenig ; Jim Schaad ; sec...@ietf.org Subject: RE: [secdir] EDHOC and Transports A minor follow-up: I mentioned that I am aware of a company using the energy scavenging devices and it turns out that this information is actually public and there is even a short video on YouTube. The company we worked with is called Alphatronics and here is the video: https://www.youtube.com/watch?v=JHpJV_CPYb4 As you can hear in the video we have been using our Mbed OS together with our device management solution (LwM2M with DTLS and CoAP) for these types of devices. [GS] Nice application of LwM2M. The showcased device didn't seem very constrained though, ARM Cortex M4? -Original Message- From: secdir On Behalf Of Hannes Tschofenig Sent: Freitag, 25. Januar 2019 13:52 To: Jim Schaad ; sec...@ietf.org Subject: Re: [secdir] EDHOC and Transports [Hannes] what we are doing here is making an optimization. For some (unknown reason) we have focused our attention to the over-the-wire transmission overhead (not code size, RAM utilization, or developer usability*). [GS] Exactly my point, it is not enough with reducing transmission overhead. We should also look at additional memory, flash, and configuration effort. These parameters are of course implementation dependent but can to some extent be inferred by bulk of specification and what pre-existing code can be reused. [Hannes] We are doing this optimization mostly based on information about what other people tell us rather than based on our experience. The problem is that we have too few people with hands-on knowledge and/or deployment experience and if they have that experience they may not like to talk about it. So, we are stepping around in the dark and mostly perceived problems. [GS] I don't think this rhetoric is very helpful. Who are "us"? The co-workers you quote below, are they "us" or the "other people"? The people active in 6tisch, lpwan or 6lo who are supporting the work on an optimized key exchange, are they "us" or the "other people"? [Hannes] Having said that I would like to provide a few remarks to your list below: [Jim] 1. Low-power devices that either are battery based or scavenge power, these devices pay a power penalty for every byte of data sent and thus have a desire for the smallest messages possible. [Hannes] Low power is a very complex topic since it is a system issue and boiling it down to the transmission overhead of every byte is an oversimplification. You are making certain assumptions of how power consumption of radio technologies work, which will be hard to verify. I have been working on power measurements recently (but only focused on power measurements of crypto, see https://community.arm.com/arm-research/b/articles/posts/testing-crypto-performance-and-power-consumption). [GS] These kind of power measurements of crypto are part of the explanation for why transmission overhead is important to reduce. Optimizations and hardware support make the crypto contribution to power consumption possible to handle, so that there is no reason to deviate from the use of current best practice crypto in security protocols even for constrained devices. The energy cost for transmission, however, is a strongly coupled to the laws of physics which sets a limit for how much they can be optimized. [Hannes] I doubt that many people on this list nor in the IETF have a lot of experience in this field to use this as a basic for an optimization. [GS] There are people in 6tisch, lpwan and 6lo who knows about power consumption and constrained characteristics. Some of them were supporting EDHOC in ACE when you were chair. [Hannes] My co-workers, who are active in this space, tell me that there is nothing like a "per byte" linear relationship (for small quantities of data) in terms of energy cost. Obviously if you trigger "an additional transmission", which requires you to ramp up a PLL, turn on radio amplifiers, send lengthy preambles etc then the incremental cost of sending 64 bytes in that packet vs 16 bytes might be immeasurable small. The critical thing appears to be how long the RF amplifiers are powered on. Hence, you will often see publications that tell you that waiting for incoming packets is actually the most expensive task (in terms of power consumption). [GS] Energy consumption generally increases with message overhead in wireless
