Re: [Secdispatch] EDHOC Summary

[Jim Schaad <[e-mail]>]

I am strongly in agreement with doing this.

> -----Original Message-----
> From: Secdispatch <[e-mail]> On Behalf Of Roman
> Danyliw
> Sent: Thursday, March 28, 2019 11:32 AM
> To: [e-mail]
> Subject: [Secdispatch] EDHOC Summary
> 
> 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/9AfqrecZfFMlMGxSXOo4
> ENZtrVk
> 
> ==[ 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/2OY2om1FjhNNBmUzwYJroHv7e
> WQ
> [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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdispatch