Re: [Secdispatch] EDHOC Summary

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

Hi Ekr,

I believe we have covered your questions in the previous discussion, here is a short summary. 

On 2019-04-11, 19:11, "Secdispatch on behalf of Eric Rescorla" <[e-mail] on behalf of [e-mail]> wrote:

    Roman, Ben,
    
    Thanks for following up on this.
    
    I agree with the assessment that it's useful to have a lightweight
    AKE protocol and that we should initiate some work to deliver that.
    It seems to me that there are still open questions about:
    
    1. Exactly what the requirements are for lightweight.

[GS] 2b and 2c provides the setting:
https://mailarchive.ietf.org/arch/msg/secdispatch/vNR7nT20fsvYjYXhAPjOpLjZGCU
Since there are different technologies and different deployment settings, it is not expected to get exact code sizes or power consumption, for example. Nevertheless specific characteristics of the technologies give distinct performance differences as is captured by the benchmarks.

    2. Whether it's necessary to design a new protocol or whether it
       is possible to adopt an existing IETF protocol (TLS seems to
       be the one where there is interest, but IKEv2 or others
       seem like other potential candidates).

    Obviously, settling the first quesiton is important to evaluate
    the second. I've heard a lot of "as light as possible", but that's
    not operationalizable. The most concrete thing I have seem is Goran's
    message of March 14, which says:
    
       Based on the best current practice AKE protocols and security levels
       used in the Internet today, certain minimum number of protocol
       messages and minimum sizes of messages are expected. We estimate lower
       bounds on messages assuming SIGMA-I, since it is 3-pass and allows
       traffic data after 1 roundtrip, and since SIGMA is considered a
       foundation for state-of-the-art AKEs. Using ECC with a security level
       of 128 bits, the size of ephemeral key and signature are commonly at
       least 32 and 64 bytes, respectively. MACs used in the constrained
       setting have a lower bound of 8 bytes. Applying these basic estimates
       on the SIGMA-I construction for an AKE authenticated with RPK:
       
        
       Message 1: >  32 bytes
       Message 2: > 104 bytes
       Message 3: >  72 bytes
       
       The corresponding estimates for an AKE authenticated with PSK are:
       
       Message 1: > 32 bytes
       Message 2: > 40 bytes
       Message 3: >  8 bytes
       
       Considering that the maximum message size for avoiding fragmentation
       is of the order of 50 bytes, for an RPK based AKE it is not possible
       to send message 2 and 3 in one frame, and not even two frames may be
       enough for message 2.
       
       Taking LoRaWAN as a benchmark, for which available frame size is at
       most 51 bytes, the lowest number of frames per message to hope for
       given the assumptions above are for PSK (1,1,1) frames, and for RPK
       (1,3,2) frames.
    
    But this is just backfiguring the requirements from what the crypto technology
    can support. Instead what needs to happen is that we need to ask what the
    deployment environment requires. 

[GS] I'm not sure I understand the problem. LoRaWAN deployment requires minimizing time-on-air and latency which implies as few frames as possible. (1,1,1) is clearly optimal but is impossible with 51 byte frames for RPK message 2 and 3 with the Sigma-I based protocol and ECC crypto used in TLS and EDHOC. 


Specifically:
    
    - Is it possible to use PSKs or is some sort of public key auth needed

[GS] Yes it is possible, this is the expected deployment in many settings. 

    - Will public keys be predistributed or do they need to be acquired
      some how (either out of band or via certs)

[GS] Both options are relevant, but considering that the work on optimizing certificate size has just started the most concrete size estimates are expected with predistributed RPK (or PSK).

    - What is the cost as a function of message size, # of frames, etc.
      and hence what the maximum sizes are.

[GS] This depends on the technologies used. Three technologies which are highly relevant for OSCORE are NB-IoT, 6TiSCH and LoRaWAN. Describing all characteristics of these technologies is not feasible, so on request we presented three benchmarks. The people who deploy these networks have confirmed that the benchmarks presented here are the relevant ones so the lightweight requirements include to perform well with respect to these benchmarks.


    For instance, imagine a scenario where you needed to use certificates
    and in which you couldn't tolerate > 64 bytes in either direction --
    it's not clear at least to me that some of these environments don't
    have exactly this setting -- then I don't believe we know how to do
    this with existing AKE technology no matter how much we compress.

[GS] As above, LoRaWAN with 51 bytes packet size is one example of that. In practice, fragmentation schemes are used, but with the penalty of latency due to duty cycle and other performance degradation due to sending multiple packets. So an optimal solution is for the message to avoid being fragmented, or being split into as few fragments as possible. 

    So, in terms of requirements, what's needed here is a document which
    describes these deployment scenarios, including the questions above,
    and then produces the requirements. Note that there may be different
    suites of requirements, e.g.,
    
    - PSK with message sizes X
    - RPK with message sizes Y
    - Certs with message sizes Z

    And of course, some of these may or may not be possible to achieve
    or require further sacrifices in order to be achievable (e.g., PFS).
    
    Now, it's possible that this document exists, but if it does not, then
    it needs to be produced and we need to have consensus on
    it. Otherwise, we're just designing in a vacuum.
    
    Once we have consensus on the requirements, then we can ask the
    question of what the right technical solution is. It seems clear that
    EDHOC is one potential input, but given that the recent work on
    slimming down the TLS handshake, it seems quite premature to assume
    that starting with EDHOC is the best approach.

[GS] The LoRaWAN and 6TiSCH benchmarks both demonstrate the penalty of not fitting into frames of the order of 50 bytes. As far as I have seen in terms of specifications, the reductions of the TLS handshake does not fit into the minimum number of frames. 

As mentioned above, the lightweight properties are characterized by the benchmarks which are provided by people deploying the technology. In addition to the lightweight requirements, the remaining requirements comes from being an AKE for OSCORE:
(see 2a of https://mailarchive.ietf.org/arch/msg/secdispatch/vNR7nT20fsvYjYXhAPjOpLjZGCU)

"At the end of the AKE the two parties should have agreed on:
- a shared secret (OSCORE Master Secret) with PFS and a good amount of randomness
- identifiers providing a hint to the receiver of what security context it should use when decrypting the message (OSCORE Sender IDs of peer endpoints), arbitrarily short
- COSE algorithms to use with OSCORE

The AKE should support the same transport as OSCORE (CoAP over foo)."

Göran

    
    
    
    
    
    
    On Thu, Mar 28, 2019 at 3:33 AM Roman Danyliw <[e-mail]> 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 <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 <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 <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 <https://mailarchive.ietf.org/arch/msg/secdispatch/-GPqswnS-DRvrAKsPbdoes4Y4lE>
    [4] 
    https://mailarchive..ietf.org/arch/msg/secdispatch/rJqvstLHo7aLfu-ODril-wIVn_0 <https://mailarchive.ietf.org/arch/msg/secdispatch/rJqvstLHo7aLfu-ODril-wIVn_0>
    [5] 
    https://docs.google.com/document/d/1wLoIexMLG3U9iYO5hzGzKjkvi-VDndQBbYRNsMUlh-k <https://docs.google.com/document/d/1wLoIexMLG3U9iYO5hzGzKjkvi-VDndQBbYRNsMUlh-k>
    [6] 
    https://mailarchive.ietf.org/arch/msg/cfrg/6WN2C2RYGTIAInE2jIUco6L9pO8 <https://mailarchive.ietf.org/arch/msg/cfrg/6WN2C2RYGTIAInE2jIUco6L9pO8>
    [7] 
    https://mailarchive.ietf.org/arch/msg/cfrg/2OY2om1FjhNNBmUzwYJroHv7eWQ <https://mailarchive.ietf.org/arch/msg/cfrg/2OY2om1FjhNNBmUzwYJroHv7eWQ>
    [8] 
    https://alessandrobruni.name/papers/18-edhoc.pdf <https://alessandrobruni.name/papers/18-edhoc.pdf>
    [9] 
    https://github.com/theisgroenbech/edhoc-proverif <https://github.com/theisgroenbech/edhoc-proverif>
    [10] 
    https://tools.ietf.org/html/draft-rescorla-tls-ctls-01 <https://tools.ietf.org/html/draft-rescorla-tls-ctls-01>
    [11] 
    https://github.com/bifurcation/mint/compare/ftls <https://github.com/bifurcation/mint/compare/ftls>
    [12] 
    https://datatracker.ietf.org/doc/charter-ietf-6tisch/ <https://datatracker.ietf.org/doc/charter-ietf-6tisch/>
    [13] 
    https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ <https://datatracker.ietf.org/doc/draft-ietf-core-object-security/>
    [14] 
    https://github.com/alexkrontiris/EDHOC-C <https://github.com/alexkrontiris/EDHOC-C>
    [15] 
    https://github.com/jimsch/EDHOC-csharp <https://github.com/jimsch/EDHOC-csharp>
    [16] 
    https://datatracker.ietf.org/doc/charter-ietf-lpwan/ <https://datatracker.ietf.org/doc/charter-ietf-lpwan/>
    [17] 
    https://datatracker..ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-join <https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-join>
    
    ==[ End ]==
    
    _______________________________________________
    Secdispatch mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/secdispatch