Subject: [Secdispatch] EDHOC Summary

From: Roman Danyliw <[email-masked]>
Date: Thu, 28 Mar 2019 10:32:01 +0000

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 ]==

---

From: Jim Schaad <[email-masked]>
Date: Thu, 28 Mar 2019 12:36:57 +0100

I am strongly in agreement with doing this.

> -----Original Message-----
> From: Secdispatch <[email-masked]> On Behalf Of Roman
> Danyliw
> Sent: Thursday, March 28, 2019 11:32 AM
> To: [email-masked]
> 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
> 
> 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 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.
> 
> ** 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.
> 
> 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).
> 
> ** 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 '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.
> 
> 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]
> 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
> [2] https://datatracker.ietf.org/meeting/interim-2019-secdispatch-
> 01/materials/slides-interim-2019-secdispatch-01-sessa-edhoc.pdf
> [4]
https://mailarchive.ietf.org/arch/msg/secdispatch/rJqvstLHo7aLfu-ODril-
> wIVn_0
> [6]
> https://mailarchive.ietf.org/arch/msg/cfrg/6WN2C2RYGTIAInE2jIUco6L9pO8
> [7]
> https://mailarchive.ietf.org/arch/msg/cfrg/2OY2om1FjhNNBmUzwYJroHv7e
> WQ
> [17]
https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-
> join
> 
> ==[ End ]==
> 
> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch

---

From: Michael Richardson <[email-masked]>
Date: Thu, 28 Mar 2019 17:25:07 +0100

...
    >> 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

I believe that that our experience with narrowly scoped short-lived WGs has
been poor.  I can't think of a positive, or really, any example.
I would dearly like this to not be the case... so maybe we can do better.
Maybe there is some RFC3999 we can try here.

I would propose (and will volunteer, unless you'd rather do this to yourself
Roman) to ask some past IESG chairs (Russ, Jari) about when we have done this
in the past, and then find out from relevant (past?) ADs if there are lessons
to be learned.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 28 Mar 2019 18:40:14 +0100

Hi Michael,

> Maybe there is some RFC3999 we can try here.

This can vary by area, but we had several examples in ART, with a single document deliverable. One example is IMAPMOVE.

Best Regards,
Alexey

---

From: Göran Selander <[email-masked]>
Date: Thu, 28 Mar 2019 18:55:02 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    next
    AKE),
    > 6TiSCH, and LoRaWAN.  The desire is to optimize the AKE to be 'as [small]
    ....
    fit
    sizes
    LPWA
    at
    radio
    into
    as
    terms of
    in
    latency
    radio
    so
    for a
    possible
    for actual
    an
    [5].
    [2].
    yet
    certain
    How
    appears that
    behavior) in
    in
    [8]
    analysis
    has no
    to

---

From: Jim Schaad <[email-masked]>
Date: Thu, 28 Mar 2019 21:27:40 +0100

> From: Secdispatch <[email-masked]> On Behalf Of Michael
> Richardson
> Sent: Thursday, March 28, 2019 5:25 PM
> To: [email-masked]
> Subject: Re: [Secdispatch] EDHOC Summary
> 
> 

I managed to get the first round of COSE done in 15 months

Jim

> Roman) to ask some past IESG chairs (Russ, Jari) about when we have done
> this in the past, and then find out from relevant (past?) ADs if there are
> lessons to be learned.
> 
> --

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 28 Mar 2019 22:45:19 +0000

CURDLE, LAMPS, and DCRUP all come to mind.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 29 Mar 2019 08:56:19 +0100

>>>> 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.
    >> 
    >> I believe that that our experience with narrowly scoped short-lived
    >> WGs has been poor.  I can't think of a positive, or really, any
    >> example.  I would dearly like this to not be the case... so maybe we
    >> can do better.  Maybe there is some RFC3999 we can try here.

    > This can vary by area, but we had several examples in ART, with a
    > single document deliverable. One example is IMAPMOVE.

That's very good to hear.
I've never heard of IMAPMOVE, which means it ran short enough that I didn't
notice it :-)
How do we repeat that kind of success?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 29 Mar 2019 03:05:18 -0500

> How do we repeat that kind of success?

A focused set of participants and WG chairs that actively push to keep the
pace up.

-Ben

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Mar 2019 08:47:55 +0000

Hiya,

FWIW, I'm neither for nor against EDHOC, but...

On 28/03/2019 10:32, Roman Danyliw wrote:
> would like to receive community feedback on the degree of support for
> this approach.

I'd guess that there's no chance of that short-lived bit happening
if people are going to continue to argue for more TLS-like variants
that do similar stuff. I've no clue if that is or is not the case.
A similar situation added a couple of years (and some angst) to
the lifetime of tcpinc.

Cheers,
S.

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 29 Mar 2019 05:10:00 -0400

> A similar situation added a couple of years (and some angst) to

This has already had 2 years added for that reason, so I'm for moving ahead
since there's interest from multiple parties to implement.

Best,
Kathleen

-- 

Best regards,
Kathleen

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 Mar 2019 10:23:16 +0100

The CoRE WG is the owner of the OSCORE specification that is often best used in conjunction with a low-resource authenticated key agreement mechanism.

At the Friday CoRE meeting at IETF104, we discussed the actions proposed below. 
Among the 30 WG members in the room, we had in-room consensus that they are the best way forward.

Grüße, Carsten

> On Mar 28, 2019, at 11:32, Roman Danyliw <[email-masked]> wrote:
> 
> Hi!
>