Re: [Ace] [Secdispatch] EDHOC

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Fri, 18 January 2019 17:15 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7140F131209; Fri, 18 Jan 2019 09:15:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whtQwVMpn-Fn; Fri, 18 Jan 2019 09:15:05 -0800 (PST)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48040130EAC; Fri, 18 Jan 2019 09:15:05 -0800 (PST)
Received: by mail-qt1-x82a.google.com with SMTP id v11so16046067qtc.2; Fri, 18 Jan 2019 09:15:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wixZX43TuwB6T/GbzLWwUGBqu3qmEYteW/wQfC/kOtU=; b=FnMtBTARVYBh7lHiYj7QNpOKLPk7grp6CP3uRTm9xW34x7tNIC83Mz2NOGtscT7+r4 LojNraGxu4cSAU9UI6zxO6fcjR4283vw7BhrhWg1qdBKuuoRFrWxQyIWA6gRgRjJ/8yd 7k+kkqSa2DqVnGBXONIUNnTssm6cvX23/4aQSzpjFg+vBpTQR82veEl8kWxBvCkLyoRf AP7XF8kv2JL26bsUdB4fh1C3kkCOpDuyc+Vb9B+/t/X5Ftc+oWBeSN24BYlNxSoDmsoj czY6c4NIGs1hh5IshgVaoBw2qlmB7sM9rZVdq3kCMwosYRipa8hhRBrC6mDCZMLGqwpo E9Hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wixZX43TuwB6T/GbzLWwUGBqu3qmEYteW/wQfC/kOtU=; b=Q/WZTQCzHOgxDclEnuQy7ftk7eJYh5DZs2wx5iB6DQRsCJi+sQkbw8lXAgrNCyhBsC zpGje6m7Fuz0YmZYKXX9pM8koYIiyOoHCRRqBCcqO2NITj0/MNJM8qEWMdQaWSOSpdGB pkmnXNey5jVQQ6CoDUWfyrR9q7oK9149O/yBl1WyTBsbpnamum2Kg8Iu0z1POJgTuZWz AqgKcYiCSUSazZpz5zfDzbSlO9yPF94IGFPeEwAD8qqNDMMUa/BRsbNuYdyrOwZE2mnG C7Lgrk+84jELt+vPwz6aq9mKLRqLivvDFB+o+Lt2wlZpi7GckTUWODnWNLBEI5V+sokR 52jQ==
X-Gm-Message-State: AJcUukfa/+UxAgizP16HDbVn9QOwag9XgSvDOnW+QY+wI6IpTKVzRGma 9I2WG+rrv4w/2wIVeaKtIeqb9Ssb
X-Google-Smtp-Source: ALg8bN73QtGwqYqNzP1RoU87Rb4vpqA6FhNkCc9TOKLlO3lg8QtdaZDOdGUqjFyNYPYEYo1d9cGEGw==
X-Received: by 2002:aed:2dc5:: with SMTP id i63mr17175873qtd.173.1547831704458; Fri, 18 Jan 2019 09:15:04 -0800 (PST)
Received: from ?IPv6:2600:380:8d54:8c15:d4de:e39b:794d:169a? ([2600:380:8d54:8c15:d4de:e39b:794d:169a]) by smtp.gmail.com with ESMTPSA id c71sm22343796qke.84.2019.01.18.09.15.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Jan 2019 09:15:03 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-D39A2768-A2D3-4A56-B949-0455BEA817F3
Mime-Version: 1.0 (1.0)
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Mailer: iPhone Mail (15E216)
In-Reply-To: <CAL02cgQvLA3P5pWzFBcK6j97gpcDOO7RRq6cm8OZjoj5soq0qQ@mail.gmail.com>
Date: Fri, 18 Jan 2019 12:15:02 -0500
Cc: =?utf-8?Q?G=C3=B6ran_Selander?= <goran.selander@ericsson.com>, "ace@ietf.org" <ace@ietf.org>, Francesca Palombini <francesca.palombini@ericsson.com>, John Mattsson <john.mattsson@ericsson.com>, "secdispatch@ietf.org" <secdispatch@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <1055DC04-EABF-4C68-907C-1321F94F5227@gmail.com>
References: <D629D980-C059-474F-B259-2700F2EEAE41@ericsson.com> <79FD6563-8ADA-4D73-B8D5-C3D70604CD76@gmail.com> <F72354EF-2FB7-41C0-BCA1-6D4511A410B2@ericsson.com> <47F03C99-68C1-4ADB-873D-F01987D66849@ipv.sx> <2E8F9AF0-4A06-49DA-B70D-7CBEF0BFA3AF@gmail.com> <CAL02cgQvLA3P5pWzFBcK6j97gpcDOO7RRq6cm8OZjoj5soq0qQ@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/dC8PeKWDrlKzEWtcbxstuNqtcGk>
Subject: Re: [Ace] [Secdispatch] EDHOC
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jan 2019 17:15:09 -0000

Sorry, I thought it was a continuation of a private thread that may also benefit from transparency and additional input.

Thank you,
Kathleen 

Sent from my mobile device

> On Jan 18, 2019, at 12:12 PM, Richard Barnes <rlb@ipv.sx> wrote:
> 
> Not sure what you mean, Kathleen.  This is a public mailing list :)
> 
>> On Fri, Jan 18, 2019 at 12:06 PM Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
>> Can that be a public thread?  It really should be.
>> 
>> Sent from my mobile device
>> 
>> > On Jan 18, 2019, at 11:54 AM, Richard Barnes <rlb@ipv.sx> wrote:
>> > 
>> > Let me provide some additional context.  When the chairs and ADs discussed this in BKK, it seemed pretty clear that EDHOC is not within the current charter of ACE — after all, ACE is targeted at authentication and authorization, not key exchange.  Since ACE would need to recharter to accept this work in any case, and because EDHOC overlapped with the interests of other working groups, it seemed to make sense to have the conversation in a broader venue.
>> > 
>> > Göran: Your email starting this thread seems like an abbreviated summary of the past discussion of this draft.  Since this is a new audience, it would be helpful if you could start from the underlying requirements (“we need an AKE with certain constraints”) and lay out why new protocol work is needed, vs. profiling existing protocols (as has been done, e.g., in DICE).
>> > 
>> > If it would be helpful to keep this moving, we could certainly arrange a virtual interim on this topic.
>> > 
>> > —Richard
>> > 
>> > 
>> >> On Jan 4, 2019, at 1:17 AM, Göran Selander <goran.selander@ericsson.com> wrote:
>> >> 
>> >> 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" <kathleen.moriarty.ietf@gmail.com> 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 <goran.selander@ericsson.com> 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
>> >>> Secdispatch@ietf.org
>> >>> https://www.ietf.org/mailman/listinfo/secdispatch
>> >> 
>> >> 
>> >