Re: [Secdispatch] EDHOC Summary

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

Hi Martin,

Comments inline, slightly overlapping with Carsten's response.

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

    On Tue, Apr 9, 2019, at 21:57, Göran Selander wrote:
    > [GS] There seems to be consensus on the summary provided by the 
    > Security ADs, which includes the problem statement.
    
    The entire point of my mail was to contest that point.

[GS] I understand that you do, but not on what grounds. A detailed problem statement is presented, summarized and an overwhelming crowd agree.
     
    > [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. 
    
    So you would prefer to disregard the work done by Eric and Jim completely?

[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] Concrete targets with numbers have been presented, for example here:
    > https://mailarchive.ietf.org/arch/msg/secdispatch/vNR7nT20fsvYjYXhAPjOpLjZGCU
    
    Presented, yes.  Agreed, no.

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

[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