Re: [Ace] [Secdispatch] EDHOC

Richard Barnes <rlb@ipv.sx> Fri, 18 January 2019 17:12 UTC

Return-Path: <rlb@ipv.sx>
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 A715D130EAC for <ace@ietfa.amsl.com>; Fri, 18 Jan 2019 09:12:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.04
X-Spam-Level:
X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 vNlrpkBBPx0g for <ace@ietfa.amsl.com>; Fri, 18 Jan 2019 09:12:16 -0800 (PST)
Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 1AEE7130E8A for <ace@ietf.org>; Fri, 18 Jan 2019 09:12:16 -0800 (PST)
Received: by mail-ot1-x32c.google.com with SMTP id f18so14979632otl.11 for <ace@ietf.org>; Fri, 18 Jan 2019 09:12:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3KEjCeMlWqTghvBIHUPsmyNJb5RGWuzSxfKVKvnpHvA=; b=NK7CbcavoJ0okf7LhDyxR8+MbF79XCqF1Ui5F8e1keuGkt0jm364SvyYMwXrZgtWFB 0H0X5lrwEQ/WjoyE7kyjUaTYsn4DyJ2AQtPArhw6xFaasMGqS2mD8hFpu91Xlt9pqpqN /JECKL/Xd9xBES/Y6pZEWhtPxN76hqewmfemC8F8biafxqqG9WsE/awv12LcN5XVX9QD EtYXht35U7F5u2iHzXm/DNWoPv8pD20rniNNzel5s20hdrFb0ZtkbcFc1UNa2zmncz4X /+z/y6EzcN0fY10hJwCDw8uXAEw3IN9kTYrvceYBdi5H3cYL+zI8wCi+tdxkv6iqq9bN k2hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3KEjCeMlWqTghvBIHUPsmyNJb5RGWuzSxfKVKvnpHvA=; b=I4ifO9tvIFMAAV+2s9am6qJdVBQ51HDUPwcoxif7yGSTeF+CjhmTeVslWYqHA8LOV/ Q6TV2YL1drU3MU5vJNET0+va3GNA8KwyxRErAo86ptCpmmAZ3AoPKNRYDSI+jjrILfg6 FL8vzkVCeMi41dgqdBDjkfJMuCtRSJ2hk3cCutz9Geu3XjiERiQwv/FSRwSHUBGXy+Hu GURK5A4AsAR7T0YTjfu8XobnsCo4xGxU9ThRhIDXnLZFvtIQ+6PK8KlNA0rsoGIEzbRE 0ky2lHN2GB69u+p2adlF4h5bcv8qnUa5yM0DSXx/ZFCMptgDWRVpWFdrG5iRSs+ssUyO ELtw==
X-Gm-Message-State: AJcUukcTsLzJt6Qqm1GQTejKc96LU/mJAuUOZgG7SXVqQftrDR5BL/C4 Y0w9Ujd40wSQi/5ozfOCPrLgmIKwIPY/T57whuazSg==
X-Google-Smtp-Source: ALg8bN6hzasix7ezN6+qk++9Sln7HfPaB0v7f291FGIt0a3sd9lXIjDh8BbKmALErBPrwO4IoUtxxyXhewaSgClho8w=
X-Received: by 2002:a9d:1b0b:: with SMTP id l11mr12992077otl.162.1547831535257; Fri, 18 Jan 2019 09:12:15 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <2E8F9AF0-4A06-49DA-B70D-7CBEF0BFA3AF@gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Fri, 18 Jan 2019 12:12:03 -0500
Message-ID: <CAL02cgQvLA3P5pWzFBcK6j97gpcDOO7RRq6cm8OZjoj5soq0qQ@mail.gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
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-Type: multipart/alternative; boundary="000000000000d4da09057fbe9cf3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/Rh7uPWa3L9Y-PCQfw-7XibfLNtQ>
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:12:20 -0000

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