Re: [Secdispatch] EDHOC Summary

["Christopher Wood" <[e-mail]>]

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" 
> <[e-mail] on behalf of [e-mail]> 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.
>    
> [GS] Concrete targets with numbers have been presented, for example here:
> https://mailarchive.ietf.org/arch/msg/secdispatch/vNR7nT20fsvYjYXhAPjOpLjZGCU
> 
>     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