Hi Kathleen,

Good question. Thanks for bringing continuity to this almost 2 years long 
offline discussion. Indeed, lack of comparison with other protocols and formal 
verification were at the time the arguments for not following up the in-room 
consensus with an email confirmation. And, as you noted, that is not the case 
anymore.

Meanwhile the ACE chairs and AD have changed. My understanding is that the 
argument now is about attracting more people with a certain security competence 
for which perhaps another WG could potentially be better, hence the request to 
Secdispatch. But I'll pass the question on and include the ACE WG for 
transparency.

From the authors' humble point of view we believe that the main missing thing 
that would enable the required further discussion is that the IETF endorses 
this work, no matter how, so that people dare invest more time in 
implementation and analysis. 

Best regards,
Göran


On 2019-01-03, 00:58, "Kathleen Moriarty" <[email protected]> 
wrote:

    Hi,
    
    I’ve read earlier versions of this draft and appreciate all the work you 
have done with the security proof and comparing to existing standardized 
protocols.  If ACE is interested, why is this going to SECDispatch? It might 
help to understand that better.  Is it that a recharter would be needed?
    
    Thank you & happy new year!
    Kathleen 
    
    Sent from my mobile device
    
    > On Jan 2, 2019, at 5:56 PM, Göran Selander <[email protected]> 
wrote:
    > 
    > Dear Secdispatch,
    > 
    > We have been advised to ask secdispatch to consider EDHOC: 
https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe
    > 
    > Those that follow the ACE WG should be familiar with this draft. The 
problem statement and motivation for EDHOC is described in section 1. In brief, 
the target is a lightweight key exchange protocol suitable for IoT 
applications, which:
    > a) has small message size and reuses existing IoT primitives to enable 
low overhead and small code footprint; 
    > b) is not bound to a particular transport, to enable end-to-end security 
in IoT deployments with varying underlying layers; and
    > c) can be used to key OSCORE (draft-ietf-core-object-security) that is 
lacking a harmonizing key exchange protocol.
    > 
    > These requirements are motivated by constrained IoT device deployments, 
but the protocol is applicable to other end-to-end security settings where the 
overhead due to security needs to be low. EDHOC addresses these requirements 
and builds on the SIGMA construction for Diffie-Hellman key exchanges. EDHOC, 
like OSCORE, is built on CBOR (RFC 7049) and COSE (RFC 8152) and the protocol 
messages may be transported with CoAP (RFC 7252).  
    > 
    > There has been a number of reviews of different versions of the draft; 
both by people who want to deploy it and by people analysing the security. A 
formal verification was presented at SSR 2018. There are a few implementations 
of different versions of the draft. The ACE WG has expressed interest in this 
work in several f2f meetings.
    > 
    > Please let us know if some information is missing for secdispatch to 
consider this draft, or how we can help out in the process.
    > 
    > Best regards
    > Göran, John, Francesca
    > 
    > 
    > _______________________________________________
    > Secdispatch mailing list
    > [email protected]
    > https://www.ietf.org/mailman/listinfo/secdispatch
    

_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace

Reply via email to