Subject: Re: [Secdispatch] [core] EDHOC Summary

From: Jari Arkko <[email-masked]>
Date: Tue, 2 Apr 2019 12:18:58 +0300

FWIW, I had not had time to look at this during the IETF week, nor did I have an opportunity to be at the CORE WG during the IETF. But I support Roman's conclusion below:

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

Jari

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 2 Apr 2019 13:36:37 +0000

Unsurprisingly I'm on the same page;

All the best,

Pascal

> -----Original Message-----
> From: core <[email-masked]> On Behalf Of Jari Arkko
> Sent: mardi 2 avril 2019 11:19
> To: Carsten Bormann <[email-masked]>; Roman Danyliw <[email-masked]>
> Cc: [email-masked]; core <[email-masked]>
> Subject: Re: [core] [Secdispatch] EDHOC Summary
> 
> FWIW, I had not had time to look at this during the IETF week, nor did I have
> an opportunity to be at the CORE WG during the IETF. But I support Roman's
> conclusion below:
> 
> >> -----[ 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.
> 
> Jari
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Laurent Toutain <[email-masked]>
Date: Tue, 2 Apr 2019 15:49:11 +0200

Hi,

I support also the creation of this WG. EDHOC is very promising for  LPWAN
networks.

Laurent

On Tue, Apr 2, 2019 at 3:37 PM Pascal Thubert (pthubert) <[email-masked]>
wrote:

> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: ana minaburo <[email-masked]>
Date: Tue, 2 Apr 2019 15:53:58 +0200

+1

Ana

On Tue, Apr 2, 2019 at 3:50 PM Laurent Toutain <
[email-masked]> wrote:

> On Tue, Apr 2, 2019 at 3:37 PM Pascal Thubert (pthubert) <
> [email-masked]> wrote:
>
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: Renzo Navas <[email-masked]>
Date: Wed, 3 Apr 2019 09:58:49 +0200

Hi all, for what it's worth,
+1 with Roman

regards,
Renzo

On Tue, Apr 2, 2019 at 3:54 PM ana minaburo <[email-masked]> wrote:

>> I support also the creation of this WG. EDHOC is very promising for
>> LPWAN networks.
>>
>> Laurent
>>

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 3 Apr 2019 19:44:51 +0000

Hello!

> From: Secdispatch [mailto:[email-masked]] On Behalf Of
> Roman Danyliw
> Sent: Thursday, March 28, 2019 6: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.

[snip]

Thanks for all of the feedback so far.  We would appreciate any additional thoughts by Monday, April 15, 2019.

Regards,
Roman and Ben

---

From: "Blomqvist, Peter" <[email-masked]>
Date: Mon, 8 Apr 2019 12:45:20 +0000

?We support the forming of a WG for EDHOC.

Best

Peter

---

From: Shahid Raza <[email-masked]>
Date: Mon, 8 Apr 2019 14:00:35 +0000

+1
We are working on the integration of OSCORE in the ITU (Intelligent Transportation Union) world.
Standardised EDHOC will certainly add a missing piece.

Best,
Shahid

Shahid Raza, PhD
Director Security Lab and Expert Researcher
RISE - Research Institutes of Sweden
Division ICT - RISE SICS

[RISE logo]     Isafjordsgatan 22 / Kistagången 16
16440, Kista Stockholm
Mobile: +46 768831797
[email-masked] <mailto:[email-masked]>
http://www.shahidraza.net
http://www.sics.se

The RISE institutes Innventia, SP and Swedish ICT have merged in order to become a stronger research and innovation partner for businesses and society.

On 3 Apr 2019, at 21:44, Roman Danyliw <[email-masked]<mailto:[email-masked]>> wrote:

Hello!

-----Original Message-----
From: Secdispatch [mailto:[email-masked]] On Behalf Of
Roman Danyliw
Sent: Thursday, March 28, 2019 6:32 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Secdispatch] EDHOC Summary

Hi!

[snip]

Regards,
Roman and Ben

_______________________________________________
Secdispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/secdispatch

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 08 Apr 2019 19:17:14 -0400

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:
> 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: Göran Selander <[email-masked]>
Date: Tue, 9 Apr 2019 11:57:52 +0000

Hi Martin,

Some comments inline.

On 2019-04-09, 01:18, "Secdispatch on behalf of Martin Thomson" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Roman, Ben,

[GS] There seems to be consensus on the summary provided by the Security ADs, which includes the problem statement.

[GS] There is no competing solution to the problem statement. As been witnessed, people have waited for years for this to progress. Therefore I don't see anything premature with assuming EDHOC to be a starting point for the WG. 

[GS] Concrete targets with numbers have been presented, for example here:
https://mailarchive.ietf.org/arch/msg/secdispatch/vNR7nT20fsvYjYXhAPjOpLjZGCU

    
   
[GS] A lightweight AKE on application layer, which this specific WG is proposed to work on, is actually a missing enabler for constrained nodes to  "communicate among themselves and with the wider Internet". Indeed, if the security protocol is too heavy or needs to terminate in a gateway due to change of transport etc., then end-to-end secure communication between the endpoints will not take place, thus preventing "to partake in permissionless innovation".  

Göran

    Cheers,
    Martin

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 09 Apr 2019 21:51:34 -0400

Hi Göran,

Please see inline below.

On Tue, Apr 9, 2019, at 4:58 AM, Göran Selander wrote:
> Hi Martin,
> 
> Some comments inline.
> 
> On 2019-04-09, 01:18, "Secdispatch on behalf of Martin Thomson" 
> <[email-masked] on behalf of [email-masked]> wrote:
> 
>     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.
> 
> [GS] There seems to be consensus on the summary provided by the 
> Security ADs, which includes 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.
> 
> [GS] There is no competing solution to the problem statement. As been 
> witnessed, people have waited for years for this to progress. Therefore 
> I don't see anything premature with assuming EDHOC to be a starting 
> point for the WG. 
> 
>     “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.
>    
> [GS] A lightweight AKE on application layer, which this specific WG is 
> proposed to work on, is actually a missing enabler for constrained 
> nodes to  "communicate among themselves and with the wider Internet". 
> Indeed, if the security protocol is too heavy or needs to terminate in 
> a gateway due to change of transport etc., then end-to-end secure 
> communication between the endpoints will not take place, thus 
> preventing "to partake in permissionless innovation".  
> 

If what’s missing is a lightweight AKE protocol, then shouldn’t the purpose of this WG be to first identify what lightweight means? To reiterate (my understanding of) Martin’s point, it seems the requirements do not have consensus, and therefore choosing a specific AKE is a bit premature. It seems prudent to first get a shared understanding of the problem space and requirements before we trim the solution space.

Best,
Chris

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 09 Apr 2019 22:57:22 -0400

> Security ADs, which includes the problem statement.

The entire point of my mail was to contest that point.
 
> I don't see anything premature with assuming EDHOC to be a starting 

So you would prefer to disregard the work done by Eric and Jim completely?
 
> https://mailarchive.ietf.org/arch/msg/secdispatch/vNR7nT20fsvYjYXhAPjOpLjZGCU

Presented, yes.  Agreed, no.

> preventing "to partake in permissionless innovation".  

I think that you missed my point.  If the goal is to provide an AKE, then any AKE will do.  If the goal is to communicate with other Internet nodes, then you might argue that any AKE will do, but you at least have to consider what existing Internet nodes do in making that call.

---

From: John Mattsson <[email-masked]>
Date: Wed, 10 Apr 2019 06:59:08 +0000

Hi Chris,

Christopher Wood <[email-masked]> wrote:

>If what’s missing is a lightweight AKE protocol, then shouldn’t the purpose of this WG be to first identify what >lightweight means? To reiterate (my understanding of) Martin’s point, it seems the requirements do not have >consensus, and therefore choosing a specific AKE is a bit premature. It seems prudent to first get a shared >understanding of the problem space and requirements before we trim the solution space.
 
The use cases and requirements for lightweight protocols including lightweight security protocols for constrained IoT have been discussed for years in the IETF IoT working groups (CORE, ACE, T2TRG, 6TiSCH, LWIG, LPWAN, 6lo, etc.). IESG took the decision a few year ago that IETF WGs should in general not do requirement and use case RFCs. RFC7228 (and RFC7228bis) gives an excellent overview of the wide span of IoT devices and networks and how utterly constrained some of them are. For the target network technologies LPWAN over LoRaWAN and 6TiSCH over IEEE 802.15.4, the requirements for message size are clear (under 50 bytes).

Cheers,
John

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 10 Apr 2019 09:26:15 +0200

> So you would prefer to disregard the work done by Eric and Jim completely?

I can’t answer that question for Göran, but personally I really like that there are now fresh proposals for addressing TLS handshake size.  Those proposals already do have a natural WG to do the work on them, the TLS WG, so no new WG is needed for those; if some rechartering of the TLS WG is required for that, I’m all for picking up that work there.

We also need a low-resource authenticated key agreement protocol that we can use now, and EDHOC is the only one I’m aware of that is in a stage of development where it can meet the timelines of the protocols depending on it.  The main problem that we have had in completing the work was that there was no WG to assign this work to, and we need to fix this now.

Grüße, Carsten

---

From: Göran Selander <[email-masked]>
Date: Wed, 10 Apr 2019 08:10:09 +0000

Hi Chris,

On 2019-04-10, 03:52, "Secdispatch on behalf of Christopher Wood" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Göran,
    
[- - -]

[GS:]

The purpose of the Secdispatch interim meeting on March 05, the preceding and following discussion was to detail the requirements (and present the results of the security analysis). Our post-interim compilation of the usual BoF questions including requirements (and specification of 'lightweight') is here:
https://mailarchive.ietf.org/arch/msg/secdispatch/vNR7nT20fsvYjYXhAPjOpLjZGCU

The security ADs' conclusion of the whole discussion and proposal for next steps, including a request for community feedback (which ended on Monday) is here: 
https://mailarchive.ietf.org/arch/msg/secdispatch/Kz_6y6Jq4HsWxglsUHafWjXIm0c

I only see a large number of people agreeing and no technical argument against.

Apologies for my impatience, but the discussion is over 2 years old. The people contesting this work has been against it for a long time and the argument has shifted from "the TLS handshake is lightweight" to "there is no need for a lightweight handshake" to "OK, we need a lightweight handshake, but not as lightweight as EDHOC". (The last statement is slightly distorting the argument, but just to give the idea.)

Göran

    Best,
    Chris

---

From: Göran Selander <[email-masked]>
Date: Wed, 10 Apr 2019 08:23:59 +0000

Hi Martin,

Comments inline, slightly overlapping with Carsten's response.

On 2019-04-10, 04:57, "Martin Thomson" <[email-masked]> wrote:

[GS] I understand that you do, but not on what grounds. A detailed problem statement is presented, summarized and an overwhelming crowd agree.

[GS] As has been repeated many times now, we would indeed like to see work on an optimized version of the TLS handshake in the TLS WG. But as that does not comply with the requirements here something else is needed in this case.

[GS] The purpose of the discussion on this mailing list and the process as presented by the security ADs was to enable a technical discussion to reach an agreement on how to dispatch. The technical discussion has been going on this list for months, a summary was presented by the ADs
(https://mailarchive.ietf.org/arch/msg/secdispatch/Kz_6y6Jq4HsWxglsUHafWjXIm0c)
 and no technical argument against has been given within the stipulated time. If that is not agreement, what is?

[GS] These are different issues. The goal with this work is to enable communication with nodes in constrained node networks and then not just any AKE is feasible. Existing Internet nodes implementing current protocols are not expected to support communication to the most constrained settings. What I wanted to highlight with my comment is that the reference you used presumes end-to-end security to constrained nodes, which is enabled by the lightweight AKE identified in this discussion.

Göran

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 Apr 2019 09:16:45 -0700

On Wed, Apr 10, 2019 at 1:10 AM Göran Selander <[email-masked]>
wrote:

> Hi Chris,
>
> On 2019-04-10, 03:52, "Secdispatch on behalf of Christopher Wood" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     Hi Göran,
>
> [- - -]
>
>     If what’s missing is a lightweight AKE protocol, then shouldn’t the
> purpose of this WG be to first identify what lightweight means? To
> reiterate (my understanding of) Martin’s point, it seems the requirements
> do not have consensus, and therefore choosing a specific AKE is a bit
> premature. It seems prudent to first get a shared understanding of the
> problem space and requirements before we trim the solution space.
>
> [GS:]
>
> The purpose of the Secdispatch interim meeting on March 05, the preceding
> and following discussion was to detail the requirements (and present the
> results of the security analysis). Our post-interim compilation of the
> usual BoF questions including requirements (and specification of
> 'lightweight') is here:
>
> The security ADs' conclusion of the whole discussion and proposal for next
> steps, including a request for community feedback (which ended on Monday)
> is here:
>

"Thanks for all of the feedback so far.  We would appreciate any additional
thoughts by Monday, April 15, 2019."

It's currently April 11.

-Ekr

> Apologies for my impatience, but the discussion is over 2 years old. The
> people contesting this work has been against it for a long time and the
> argument has shifted from "the TLS handshake is lightweight" to "there is
> no need for a lightweight handshake" to "OK, we need a lightweight
> handshake, but not as lightweight as EDHOC". (The last statement is
> slightly distorting the argument, but just to give the idea.)
>
> Göran
>
>
>     Best,
>     Chris
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 11 Apr 2019 13:02:26 -0400

Hi all,

Sorry for the late-ish reply.  I wanted to write some code to confirm my
thoughts here and provide some concrete data.

tl;dr:
* EDHOC is not ALARP, both in the “AL” and “RP” senses
* TLS, unmodified, can be compressed to within a factor of 2 of EDHOC
* TLS can be tweaked to be smaller than EDHOC while making fewer sacrifices
cryptographically
* For the RPK case, with TLS numbers from implementation, not specification:
    * EDHOC = (39, 120, 85)
    * TLS compressed = (64, 180, 116)
    * TLS with similar but smaller sacrifices = (32, 113, 81)

It’s well-established at this point that EDHOC makes some cryptographic
compromises vis à vis TLS that not everyone is comfortable with.  Namely,
(1) it omits the random values sent in the TLS ClientHello and ServerHello
messages, and (2) it relies on an AEAD authentication tag in the role that
the Finished MAC plays in TLS.  The uncertainty around these optimizations
raises two questions:

1. How small can a TLS handshake be made *without* making these compromises?
2. If we make analogous compromises in TLS, what is the minimum message
size?

To answer these questions empirically, I made a fork of the mint TLS 1.3
library that implements these modifications for the RPK case.  You can see
the diff at the following URL; it's about 800 extra LoC:

https://github.com/bifurcation/mint/compare/ctls

(The PSK case would be straightforward, just didn’t have time.)

# Compressing TLS

We start from the observation that simply re-encoding TLS messages doesn’t
change the security proofs at all.  If the inputs to the cryptographic
functions are the same, then you get the same assurances regardless of
whether you get them off the wire or prenegotiate them.  If you assume, as
EDHOC does, that the negotiation bits of TLS can be done out of band, then
you can make a compression layer that, on sending, removes all those
unnecessary bits, and on receiving, reconstructs the original message using
the prenegotiated values.

If you do that with the standard TLS mutual-auth handshake, then you arrive
at the following message sizes and allocations of bytes:

TLS-RPK-ZIP: (64, 180, 116)
M1: 32 [rand] + 32 [DH]
M2: 32 [rand] + 32 [DH] + 4 [CertID] + 64 [SIG] + 32 [MAC] + 16 [TAG]
M3: 4 [CertID] + 64 [SIG] + 32 [MAC] + 16 [TAG]

This seems like a pretty compelling result in itself, since you get the
full power of TLS here in terms of assurance — including things like
downgrade protection on however you did the prenegotiation.  And you get it
all with less than 2x the message size of EDHOC.

# Tweaking TLS in Questionable Ways

Now let’s consider the EDHOC shortcuts noted above.  The removal of the
random values seems more plausible to me, since the DH values contribute
fresh randomness anyway.  So we can tweak the TLS stack to set the randoms
to zero, and we no longer have to send them in our messages:

TLS-ZIP-NORAND: (32, 148, 116)
M1: 32 [DH]
M2: 32 [DH] + 4 [CertID] + 64 [SIG] + 32 [MAC] + 16 [TAG]
M3: 4 [CertID] + 64 [SIG] + 32 [MAC] + 16 [TAG]

Already, we’ve surpassed EDHOC on the first message.  Removing the Finished
message is dicier, since it introduces the authentication concerns that
have been discussed elsewhere.  In TLS, we can “virtualize” the Finished
message; since each side can compute the Finished MAC, they can include it
in the key schedule even if it’s not sent.  If we do that, then we end up
below EDHOC’s message sizes:

TLS-RPK-ZIP-NORAND-VFIN: (32, 113, 81)
M1: 32 [DH]
M2: 32 [DH] + 1 [CertID] + 64 [SIG] + 16 [TAG]
M3: 1 [CertID] + 64 [SIG] + 16 [TAG]

This is an interesting structure to compare to EDHOC.  First, it’s notable
that we got here with fewer sacrifices than EDHOC.  Where EDHOC uses 8-bit
tags, we use full-size.  And the fact that Finished MACs end up in the key
schedule mean that at least the application keys will diverge if the
parties disagree.  (The things in EDHOC that this TLS variant lacks, like
connection IDs, can be added back at similar cost.)  Second, this
highlights how many bytes EDHOC wastes on framing:

EDHOC-RPK:
M1: 39  = 32 [DH] + 1 [msgType] + 1 [CID] + 2 [ciphers] + 3 [framing]
M2: 120 = 32 [DH] + 4 [KID] + 64 [SIG] + 8 [TAG] + 2 [CID] + 10 [framing]
M3: 85  = 4 [KID] + 64 [SIG] + 8 [TAG] + 1 [CID] + 8 [framing]

In summary, having taken a pretty deep dive on this problem, it’s not clear
at all to me that if you want a lightweight AKE (regardless of the
definition of “lightweight”) that EDHOC is the best starting point.  We can
get most of the way there just by profiling down TLS, and if we need to go
farther, we get more savings with higher assurance by tweaking TLS than we
do with a clean-slate design like EDHOC.

—Richard

On Thu, Mar 28, 2019 at 6:33 AM Roman Danyliw <[email-masked]> wrote:

> assessment of the current state of this discuss and as well as proposed
> next steps are below.
>
> Regards,
> Roman and Ben
>
> [1]
> 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.
>
> 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].
> 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.
>
> 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.
>
> 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.
>
> TLS/CoAP-variant.  How this impacts the original assumptions and security
> analysis for (D)TLS is unknown.
>
> ** 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
>
> (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.
>
> possible.  However, as of yet, cTLS is an incomplete specification, cTLS
> has no formal security analysis, and is technically a new protocol.
>
> -----[ Conclusion
>
> engineer.  Among the available starting points to address the problem
> defined in question #1, EDHOC presents a viable choice.
>
> [6] https://mailarchive.ietf.org/arch/msg/cfrg/6WN2C2RYGTIAInE2jIUco6L9pO8
> [7] https://mailarchive.ietf.org/arch/msg/cfrg/2OY2om1FjhNNBmUzwYJroHv7eWQ

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 Apr 2019 10:10:15 -0700

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

- Is it possible to use PSKs or is some sort of public key auth needed
- Will public keys be predistributed or do they need to be acquired
  some how (either out of band or via certs)
- What is the cost as a function of message size, # of frames, etc.
  and hence what the maximum sizes are.

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.

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.

-Ekr

---

From: Richard Barnes <[email-masked]>
Date: Thu, 11 Apr 2019 14:59:01 -0400

On Wed, Apr 10, 2019 at 3:26 AM Carsten Bormann <[email-masked]> wrote:

> I can’t answer that question for Göran, but personally I really like that
> there are now fresh proposals for addressing TLS handshake size.  Those
> proposals already do have a natural WG to do the work on them, the TLS WG,
> so no new WG is needed for those; if some rechartering of the TLS WG is
> required for that, I’m all for picking up that work there.
>
> We also need a low-resource authenticated key agreement protocol that we
> can use now, and EDHOC is the only one I’m aware of that is in a stage of
> development where it can meet the timelines of the protocols depending on
> it.

I'd like to push back on this point.  It may be that EDHOC has been around
for a while and been well-socialized with the IoT crowd, but it is clearly
deficient in several other types of maturity, e.g., robustness of formal
analyses and state of implementations (AFAICT).

--Richard

> The main problem that we have had in completing the work was that there
> was no WG to assign this work to, and we need to fix this now.
>
> Grüße, Carsten
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Apr 2019 15:15:00 -0400

Richard Barnes <[email-masked]> wrote:
    > I'd like to push back on this point. It may be that EDHOC has been around for
    > a while and been well-socialized with the IoT crowd, but it is clearly

I want to be sure that I understand you.

Is it your opinion tha the IETF can not form a WG until after a protocol has
had formal analysis?  How many analysis?  How many years?  Which publications?

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

---

From: Richard Barnes <[email-masked]>
Date: Thu, 11 Apr 2019 15:20:35 -0400

> had formal analysis?  How many analysis?  How many years?  Which

I didn't mean anything w.r.t. the formation of a WG.  Carsten's implication
seemed to be that an EDHOC WG could deliver more quickly than, e.g., one
using TLS as a starting point.  That's the point I was pushing back on -- I
hope we agree that delivering a final security protocol should be gated on
robust analysis and multiple implementations.

--Richard

---

From: Göran Selander <[email-masked]>
Date: Thu, 11 Apr 2019 20:16:02 +0000

"Thanks for all of the feedback so far.  We would appreciate any additional thoughts by Monday, April 15, 2019."

    It's currently April 11.

Oops, wrong Monday.
    
Göran

---

From: Göran Selander <[email-masked]>
Date: Thu, 11 Apr 2019 21:30:25 +0000

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

    Roman, Ben,

    

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

    

       Message 1: >  32 bytes
       Message 2: > 104 bytes
       Message 3: >  72 bytes

       Message 1: > 32 bytes
       Message 2: > 40 bytes
       Message 3: >  8 bytes

    
    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:

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

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

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

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

    

[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

    

    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

    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]

    
    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.

    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.

    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

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

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 12 Apr 2019 01:16:13 +0300

John Mattsson writes:
> constrained some of them are. For the target network technologies
> LPWAN over LoRaWAN and 6TiSCH over IEEE 802.15.4, the requirements
> for message size are clear (under 50 bytes).

IEEE 802.15.9 specifies how to use KMPs in IEEE 802.15.4, and it
provides fragmentation of larger messages, so message size limits are
not absolute in IEEE 802.15.4 environment. Of course the fewer
fragments are needed the more efficient the protocol will be, but
there is no absolute limit that is required.

Some of the PHYs in IEEE 802.15.4 support larger frame sizes (up to
2048 bytes) and some of them support smaller (smallest are 20-30 bytes
or so, but that PHY also includes another layer of fragmentation).

The most common maximum frame size is 127 bytes, including header, and
the header is usually less than 20 octets if no security header is
used (which normally is not used for key management protocols as there
is no keys yet). Even with security the overhead is usually about 12
bytes more, thus the total overhead is around 20-40 bytes. This means
there is space for around 80-100 bytes of actual frame payload for
IEEE 802.15.4 in normal cases.

Targetting for 50 bytes is quite pessimistic for IEEE 802.15.4.
-- 
[email-masked]

---

From: Göran Selander <[email-masked]>
Date: Thu, 11 Apr 2019 22:48:06 +0000

Hi Richard,

I like your ambition to optimize further. But if you change TLS by copying over features from EDHOC then of course message sizes will become on par since they are both based on Sigma-I. It is not clear to me what is left of TLS after 
"Tweaking TLS in Questionable Ways" as it is neither compatible with TLS, nor does the security proofs automatically carry over. 

Please find further comments inline.

On 2019-04-11, 19:02, "Secdispatch on behalf of Richard Barnes" <[email-masked] on behalf of [email-masked]> wrote:

    Hi all,
    
    Sorry for the late-ish reply.  I wanted to write some code to confirm my thoughts here and provide some concrete data.
    
    tl;dr: 
    * TLS can be tweaked to be smaller than EDHOC while making fewer sacrifices cryptographically

[GS] Please use the current version (-13) of EDHOC in your comparison, the numbers here are not correct. Please also make sure that you compare protocols which have the same features. For example Connection identifiers are missing, and it is not clear to me how you negotiate COSE algorithms for EDHOC and OSCORE in your implementation. Therefore the comparisons made in this mail are void.
    
    It’s well-established at this point that EDHOC makes some cryptographic compromises vis à vis TLS that not everyone is comfortable with. 

[GS] Neither the formal analysis, nor the two CFRG crypto panel reviews made any remarks of that kind.

 Namely, (1) it omits the random values sent in the TLS ClientHello and ServerHello messages, and (2) it relies on an AEAD
     authentication tag in the role that the Finished MAC plays in TLS.  The uncertainty around these optimizations raises two questions:
    
    1. How small can a TLS handshake be made *without* making these compromises?
    2. If we make analogous compromises in TLS, what is the minimum message size?
    
    To answer these questions empirically, I made a fork of the mint TLS 1.3 library that implements these modifications for the RPK case.  You can see the diff at the following URL; it's about 800 extra LoC:

    # Compressing TLS
    
    We start from the observation that simply re-encoding TLS messages doesn’t change the security proofs at all.  If the inputs to the cryptographic functions are the same, then you get the same assurances regardless of whether you get them off the wire or prenegotiate
     them.  If you assume, as EDHOC does, that the negotiation bits of TLS can be done out of band

[GS] No, cipher negotiation must be included and is done in EDHOC.

, then you can make a compression layer that, on sending, removes all those unnecessary bits, and on receiving, reconstructs the original message using the prenegotiated
     values..
    
    If you do that with the standard TLS mutual-auth handshake, then you arrive at the following message sizes and allocations of bytes:

    This seems like a pretty compelling result in itself, since you get the full power of TLS here in terms of assurance — including things like downgrade protection on however you did the prenegotiation.  And you get it all with less than 2x the message size of
     EDHOC.

[GS] As this does not fit into the optimal number of frames for e.g. LoRaWAN it is not a candidate solution.

    Now let’s consider the EDHOC shortcuts noted above.  The removal of the random values seems more plausible to me, since the DH values contribute fresh randomness anyway.  So we can tweak the TLS stack to set the randoms to zero, and we no longer have to send
     them in our messages:

    Already, we’ve surpassed EDHOC on the first message.  Removing the Finished message is dicier, since it introduces the authentication concerns that have been discussed elsewhere.  In TLS, we can “virtualize” the Finished message; since each side can compute
     the Finished MAC, they can include it in the key schedule even if it’s not sent.  If we do that, then we end up below EDHOC’s message sizes:

    This is an interesting structure to compare to EDHOC.  First, it’s notable that we got here with fewer sacrifices than EDHOC.  Where EDHOC uses 8-bit tags, we use full-size.  And the fact that Finished MACs end up in the key schedule mean that at least the
     application keys will diverge if the parties disagree.  (The things in EDHOC that this TLS variant lacks, like connection IDs, can be added back at similar cost.)  Second, this highlights how many bytes EDHOC wastes on framing:
    
    EDHOC-RPK:

[GS] The "framing" here is partly CBOR, which is a feature and not a bug.
    
    In summary, having taken a pretty deep dive on this problem, it’s not clear at all to me that if you want a lightweight AKE (regardless of the definition of “lightweight”) that EDHOC is the best starting point.  We can get most of the way there just by profiling
     down TLS, and if we need to go farther, we get more savings with higher assurance by tweaking TLS than we do with a clean-slate design like EDHOC.

[GS] The EDHOC you compare with is a formally verified protocol, whereas this is an email, so it remains to prove the properties you claim. On a positive note, I see a convergence in the protocol you sketch and EDHOC, but there are still some features you need to add, like CBOR and cipher suite negotiation.

Göran

    

    Hi!

    Regards,
    Roman and Ben
    
    [1] 
    
    ==[ Summary of ADs ]==
    EDHOC Summary

    

    

    

    

    

    

    

    
    -----[ Conclusion

    
    -----[ References
    [1] 
    
    ==[ End ]==

---

From: Göran Selander <[email-masked]>
Date: Thu, 11 Apr 2019 23:08:56 +0000

Hi Richard,

On 2019-04-11, 21:21, "Richard Barnes" <[email-masked]> wrote:

    On Thu, Apr 11, 2019 at 3:15 PM Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:

    

    I didn't mean anything w.r.t. the formation of a WG.  Carsten's implication seemed to be that an EDHOC WG could deliver more quickly than, e.g., one using TLS as a starting point.  That's the point I was pushing back on -- I hope we agree that delivering
     a final security protocol should be gated on robust analysis and multiple implementations.

[GS] As I mentioned in my recent reply, given the changes you make to TLS to make message sizes on par with EDHOC, it is a new protocol so the statement about relying on the analysis of TLS is questionable. Comparing implementations there are clearly more of TLS, but, again, this is a new protocol. 

Göran

    --Richard

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

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 12 Apr 2019 03:08:22 +0300

Göran Selander writes:
> [GS] As I mentioned in my recent reply, given the changes you make
> to TLS to make message sizes on par with EDHOC, it is a new protocol
> so the statement about relying on the analysis of TLS is
> questionable. Comparing implementations there are clearly more of
> TLS, but, again, this is a new protocol.

I do not think it is new protocol, it could be done by just applying
static header compression to TLS.

Making static context header compression rules, that will omit for
example most of the TLS framing which are not needed (as they are
static) will allow take normal TLS frame, compress it to much smaller
frame to be sent to other end.

Then on the other end the static context header compression rules will
decompress the frame and will get exactly same full TLS frame that was
in the sender end. From the TLS library point of view the packets are
full TLS 1.3 packets without any modifications. There might be some
constrains what kind of TLS 1.3 frames the compression can do, for
example there might be constraints that there cannot be any generic
extensions, i.e., the TLS library would need to be configured so it
will never even try to use them, the length of nonce might be fixed to
specific length etc.
-- 
[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 12 Apr 2019 04:34:55 +0200

On Apr 12, 2019, at 02:08, Tero Kivinen <[email-masked]> wrote:
> 
> it could be done by just [doing something contorted].

Sure, it could be (we have a lot of experience with header compression).
(It is actually the only way to claim that we are “doing TLS”, as opposed to a new thing that just happens to be TLS-branded as well).

But if that were the way forward, we would do compressed JSON over compressed HTTP over compressed TCP over compressed IP.  (Actually, we *are* compressing IP, because a concise IP would be a nonstarter…)

Some people are actually using heavy compression in their stacks (hey, we just registered a deflated JSON Content-Format for CoAP!).  But generally:

   Concise wins over compressed.

Grüße, Carsten

---

From: Göran Selander <[email-masked]>
Date: Fri, 12 Apr 2019 11:57:20 +0000

Hi Tero,

On 2019-04-12, 00:16, "Tero Kivinen" <[email-masked]> wrote:

    

[GS] This benchmark provided by 6TiSCH is looking at bootstrapping in a multihop network using the 6tisch minimal security setup with a stateless join proxy, which is how the AKE is planned to be used in this context. The statelessness of the proxy leads to additional overhead in the network.

Göran

---

From: Jim Schaad <[email-masked]>
Date: Sat, 13 Apr 2019 15:38:37 -0700

> From: Secdispatch <[email-masked]> On Behalf Of Martin
> Thomson
> Sent: Tuesday, April 9, 2019 7:57 PM
> To: Göran Selander <[email-masked]>; [email-masked]
> Subject: Re: [Secdispatch] EDHOC Summary
> 
> > witnessed, people have waited for years for this to progress.
> > Therefore I don't see anything premature with assuming EDHOC to be a
> > starting point for the WG.
> 

Don't forget that one of the issues that was identified by me was that by the time I was finished I felt that an entirely new security analysis was going to be required to make sure that nothing was broken.

Jim

> I think that you missed my point.  If the goal is to provide an AKE, then any
> AKE will do.  If the goal is to communicate with other Internet nodes, then
> you might argue that any AKE will do, but you at least have to consider what
> existing Internet nodes do in making that call.
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 19 Apr 2019 00:44:58 -0500

Hi Martin,

Sorry for the slow response.  Roman and I were both separately out of
commission for several days (non-overlapping, per Murphy's law), and so it
was hard to sync up.

On Mon, Apr 08, 2019 at 07:17:14PM -0400, Martin Thomson wrote:
> 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.

We agree that there was a need to clarify the scope and nature of the
requirements coming out of the virtual interim meeting.  However, we felt
that many of the open questions were ultimately clarified in follow-on
discussion and through detailed review of the materials that were prepared,
but not adequately presented due to time constraints.  Thus, we tried to
put in a lot of specific references to actual concrete scenarios, data, and
use cases.

The summary below leveraged your early insight [1] prior to the virtual
interim meeting to use the four new work questions to organize what have
been discussed, presented and prepared, in a familiar format.

> There has been some discussion on the list on this subject, but I haven’t
> seen anything that indicates consensus around the problem statement.
> 

We view the problem statement as essentially your question #1, "what is the
problem we are faced with?"

During the meeting and in follow-up discussions, we heard a diversity of
opinions but no push back that (per the summary below) "the community needs
an AKE that is 'lightweight' and enables forward security for constrained
environments".

> 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
> ways that affect these deployments.

We concur that there is agreement that current AKE protocols are
inefficient in certain deployments.  As noted above, this is why we feel
that question #1 has been answered. 

> That doesn’t naturally imply that EDHOC is a solution, only that there is
> a need to have an efficient AKE protocol.

Correct.  For this reason, the summary below walked through the four new-work
questions and evaluated the published solutions available at the time.

> “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 protoc…

We believe that such specificity is the essence of questions #2 and #3, and
again, we tried to use specific references to material that has already
been presented, to shape our picture of what the answers to those questions
are.

We agree that "as cheap as possible" is not clear.  For these reason,
question #2 outlines slightly more specific metrics for the individual
protocols (but not down to specific byte counts).  In the case of certain
active IETF work which would use this AKE, specifically 6Tisch, it has been
confirmed that we can get a usable key exchange mechanism even though the
overhead and the constraint of fitting into a single MTU limits the hop
count over which the key exchange is performed.

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

We can't disagree with the vision of suggested by T2TRG.  However, how this
vision reframes the answers summarized below to the scoping questions isn't
clear.  Are we supposed to not even try to solve problems in front of IETF
WGs because they don't fit into a grand vision?  It seems we should hope to
find engineering solutions, complete with the engineering compromises that
entails.

Regards,

Ben and Roman

[1] https://mailarchive.ietf.org/arch/msg/secdispatch/7G3vjVvoYyWXUB3qtqhLqd90AXs

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 19 Apr 2019 00:50:35 -0500

> [GS] There seems to be consensus on the summary provided by the Security ADs, which includes the problem statement.

Well, I don't think we really have had a chance to gather great data about
whether there is consensus around the summary that Roman and I collated.
But, as noted in my message to Martin just now, we aren't really seeing
opposition to providing a lightweight AKE for usage in constrained
scenarios, such as those that were presented at the interim.

> [GS] There is no competing solution to the problem statement. As been witnessed, people have waited for years for this to progress. Therefore I don't see anything premature with assuming EDHOC to b…

I think some people are trying to propose competing solutions (in various
forms) as part of this thread.  Per IETF tradition, of course, such things
are easier to evaluate when in I-D form than just sketched out in emails.

-Ben