Re: [Secdispatch] EDHOC Summary

[Göran Selander <[e-mail]>]

Hi Roman, Ben, 

I agree, this seems to be a good way forward. 

Göran

On 2019-03-28, 12:37, "Secdispatch on behalf of Jim Schaad" <[e-mail] on behalf of [e-mail]> wrote:

    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
    
    _______________________________________________
    Secdispatch mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/secdispatch