Re: [Secdispatch] EDHOC Summary

Hi Roman, Ben,

I’m a little surprised to see that your conclusion from the meeting we had was so clear. The summary shared at the end of the meeting highlighted the need to clarify the scope and nature of the requirements. There has been some discussion on the list on this subject, but I haven’t seen anything that indicates consensus around the problem statement.

The framing of this summary seems to imply that the goal is to work on EDHOC.  That seems premature.  There seems to be agreement that the authenticated key exchange (AKE) protocols we have are inefficient in ways that affect these deployments. That doesn’t naturally imply that EDHOC is a solution, only that there is a need to have an efficient AKE protocol.

“As cheap as possible” is not a problem statement that is sufficiently precise to be acted upon.  For example, the analysis for LoRaWAN seemed to support the conclusion that ANY key exchange protocol would fail badly, no matter how small, fast, or efficient.  For deployments with capabilities that might support an AKE, we have no grounds for determining whether 5nJ or 1 octet difference is acceptable or not. Concrete objectives - ideally targets with numbers - are needed if we’re to assess solutions.

Even assuming that requirements are settled, I believe that there are considerations that go beyond the narrow definition of the problem statement. In the recent review of the T2TRG, I was reminded of their goal:

> The Thing-to-Thing Research Group (T2TRG) will investigate open research issues in turning a true "Internet of Things" into reality, an Internet where low-resource nodes ("things", "constrained nodes") can communicate among themselves and with the wider Internet, in order to partake in permissionless innovation.

Though a little wordy, I think that this is a fine goal to keep in mind.  Deciding to create a working group specifically for EDHOC makes a determination directly in opposition to this goal.  We’ve made similar choices for application protocols like CoAP.  For CoAP, the agreed fix was gateways and proxies.  For a security protocol, that is not an option if you value end-to-end security.

Cheers,
Martin

On Thu, Mar 28, 2019, at 21:33, Roman Danyliw wrote:
> Hi!
> 
> We have observed the continued discussion and interest in the topics 
> discussed at the March 2019 Virtual Interim Secdispatch meeting [1].  
> Our assessment of the current state of this discuss and as well as 
> proposed next steps are below.
> 
> Regards,
> Roman and Ben
> 
> [1] 
> https://mailarchive.ietf.org/arch/msg/secdispatch/9AfqrecZfFMlMGxSXOo4ENZtrVk
> 
> ==[ Summary of ADs ]==
> EDHOC Summary
> 
> -----[ 1. What is the problem we are faced with?
>  
> The community needs an AKE that is 'lightweight' (per slide #3 of [2]) 
> and enables forward security for constrained environments using OSCORE 
> [13].  'Lightweight' refers to:
>  
> ** resource consumption, measured by bytes on the wire, wall-clock time 
> to complete (i.e., the initial latency added to application protocols 
> by the AKE), or power (per slide #12 of [2])
> ** the amount of new code required on end systems which already have an 
> OSCORE stack [4] 
>  
> -----[ 2. Is the problem understood and narrowly scoped?
> 
> Use with OSCORE implicitly assumes that this AKE would support:
> ** transport over CoAP, and
> ** COSE algorithms
> 
> The specific constrained environments that we are considering use 
> NB-IoT, 6TiSCH, and LoRaWAN.  The desire is to optimize the AKE to be 
> 'as [small] ... as reasonably achievable' (per [3]) in these 
> environments.
> 
> ** With respect to 6TiSCH, IETF consensus on the 6TiSCH WG charter has 
> already identified the need to "secur[e] the join process and mak[e] 
> that fit within the constraints of high latency, low throughput and 
> small frame sizes that characterize IEEE802.15.4 TSCH." [12].
> ** With respect to NB-IoT and LoRaWAN, IETF consensus on the LPWAN WG 
> charter has identified the need to improve the transport capabilities 
> of LPWA networks such as NB-IoT and LoRa whose "common traits include 
> ... frame sizes ... [on] the order of tens of bytes transmitted a few 
> times per day at ultra-low speeds" [16]. This indicates IETF interest 
> in supporting these radio environments, though no security-specific 
> requirements are included in the charter.
>  
> It may be necessary to evaluate options that make different trade-offs 
> across a number of dimensions.
>  
> ** Per 'bytes on the wire', it is desirable for these AKE messages to 
> fit into the MTU size of these protocols; and if not possible, within 
> as few frames as possible.  Note that using multiple MTUs can have 
> significant costs in terms of time and power (listed below). For 6TiSCH 
> specifically, as a time-sliced network, this metric (or rather, the 
> quantization into frame count) is particularly noteworthy, since more 
> frames contribute  to congestion for spectrum (and concomitant error 
> rates) in a non-linear way, especially in scenarios when large numbers 
> of independent nodes are attempting to execute an AKE to join a network.
>  
> ** Per 'time', it is desirable for the AKE message exchange(s) to 
> complete in a reasonable amount of time, both for a single uncongested 
> exchange and when multiple exchanges are running in an interleaved 
> fashion.  This latency may not be a linear function depending on 
> congestion and the specific radio technology used.  For LoRaWAN, which 
> is legally required to use a 1% (or smaller) duty cycle, a payload 
> split into two fragments instead of one increases the time to complete 
> the sending of this payload by 10,000% (per slide #10 of [2]).  
>  
> ** Per 'power', it is desirable for the transmission of AKE messages 
> and crypto to draw as little power as possible  The best mechanism for 
> doing so differs across radio technologies.  For example, NB-IoT uses 
> licensed spectrum and thus can transmit at higher power to improve 
> coverage, making the transmitted byte count relatively more important 
> than for other radio technologies.  In other cases, the radio 
> transmitter will be active for a full MTU frame regardless of how much 
> of the frame is occupied by message content, which makes the byte count 
> less sensitive for the power consumption.  Increased power consumption 
> is unavoidable in poor network conditions, such as most wide-area 
> settings including LoRaWAN.
> 
> ** Per 'new code', it is desirable to introduce as little new code as 
> possible onto OSCORE-enabled devices to support this new AKE.  These 
> devices have on the order of 10s of kB of memory and 100s of kB of 
> storage on which an embedded OS; a COAP stack; CORE and AKE libraries; 
> and target applications would run.  It is expected that the majority of 
> this space is  available for actual application logic, as opposed to 
> the support libraries.
> 
> A key question to answer is whether any new solution will reduce these 
> properties to a sufficient extent to merit investment.
>  
> -----[ 3. Do we believe it is possible to engineer a solution?
> 
> EDHOC [1] appears to be an existence proof that it is possible to 
> produce an AKE that meaningfully reduces the costs across at least two 
> dimensions identified in question #1 and 2 (bytes and time).  
> 
> EDHOC appears to favorably outperform TLS/CoAP, the current technology, 
> relative to these dimensions. 
>  
> ** Per 'bytes on the wire', MTU sizes and their alignment to the size 
> of messages of EDHOC vs. TLS/CoAP can be found in slide #33 of [2], and 
> in [5].  Additional details for 6TiSCH in particular can be found in 
> slide 36-37 of [2].
>  
> ** Per 'time', the latency due to back-off time estimates with EDHOC 
> vs. TLS/CoAP using LoRaWAN can be found in slide #39 of [2]
>  
> ** Per 'power', estimates of the power usage of EDHOC vs TLS/CoAP using 
> NB-IoT can be found in slide #35 of [2] 
>  
> ** Per 'new code', being able to reuse primitives from the existing 
> COSE stack is expected to benefit the code size for EDHOC, but no hard 
> data is yet available for comparison.  
> 
> Exploratory work with cTLS [10] and femtoTLS [11] has suggested that 
> certain optimizations used in EDHOC can also be applied to a 
> TLS/CoAP-variant.  How this impacts the original assumptions and 
> security analysis for (D)TLS is unknown. 
>  
> -----[ 4. Is this particular proposal a good basis for working on? 
> 
> EDHOC shows gains in defining an AKE with forward secrecy that is 
> 'reasonably small[er]' than the baseline of (D)TLS.  Specifically, it 
> appears that EDHOC would enable:
> ** for 6TiSCH, a more efficient network join operation, with network 
> join traffic fitting in one frame per flight (that is, the optimal 
> possible behavior) in up to a 5-hop network [17]
> ** for LoRaWAN, an AKE with forward secrecy that avoids the 
> unacceptable backoff-induced latency 
> 
> A limited interop was performed on draft-selander-ace-cose-ecdhe-05 
> (EDHOC) at IETF 98 between [14] and [15].  Despite the inherent 
> challenges of producing a new AKE that is secure, there is reason to 
> have confidence in the security claims made by EDHOC -- the security 
> properties of -08 were formally verified by [8][9].  Identified issues 
> from this formal analysis [8] were addressed in -11.  The CFRG crypto 
> review panel conducted two reviews [6][7].  These reviews confirmed 
> that the security claims are reasonable, attested that the identified 
> issues found in the formal analysis [8] were fixed, and provided 
> additional recommendations.
>  
> Re-encoding of the TLS handshake as suggested by cTLS [10] may be 
> possible.  However, as of yet, cTLS is an incomplete specification, 
> cTLS has no formal security analysis, and is technically a new protocol.
> 
> -----[ Conclusion
> 
> There appears to be an understood and scoped problem that is feasible 
> to engineer.  Among the available starting points to address the 
> problem defined in question #1, EDHOC presents a viable choice.  
> 
> Chartering a narrowly scoped, short-lived WG in this space with EDHOC 
> as a starting point seems to be an attractive path forward, but we 
> would like to receive community feedback on the degree of support for 
> this approach.
> 
> -----[ References
> [1] https://www.ietf.org/id/draft-selander-ace-cose-ecdhe-13.txt
> [2] 
> https://datatracker.ietf.org/meeting/interim-2019-secdispatch-01/materials/slides-interim-2019-secdispatch-01-sessa-edhoc.pdf
> [3] 
> https://mailarchive.ietf.org/arch/msg/secdispatch/-GPqswnS-DRvrAKsPbdoes4Y4lE
> [4] 
> https://mailarchive.ietf.org/arch/msg/secdispatch/rJqvstLHo7aLfu-ODril-wIVn_0
> [5] 
> https://docs.google.com/document/d/1wLoIexMLG3U9iYO5hzGzKjkvi-VDndQBbYRNsMUlh-k
> [6] 
> https://mailarchive.ietf.org/arch/msg/cfrg/6WN2C2RYGTIAInE2jIUco6L9pO8
> [7] 
> https://mailarchive.ietf.org/arch/msg/cfrg/2OY2om1FjhNNBmUzwYJroHv7eWQ
> [8] https://alessandrobruni.name/papers/18-edhoc.pdf
> [9] https://github.com/theisgroenbech/edhoc-proverif
> [10] https://tools.ietf.org/html/draft-rescorla-tls-ctls-01
> [11] https://github.com/bifurcation/mint/compare/ftls
> [12] https://datatracker.ietf.org/doc/charter-ietf-6tisch/
> [13] https://datatracker.ietf.org/doc/draft-ietf-core-object-security/
> [14] https://github.com/alexkrontiris/EDHOC-C
> [15] https://github.com/jimsch/EDHOC-csharp
> [16] https://datatracker.ietf.org/doc/charter-ietf-lpwan/
> [17] 
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-join
> 
> ==[ End ]==
> 
> _______________________________________________
> Secdispatch mailing list
> Secdispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/secdispatch
>