Re: [Ace] [Secdispatch] EDHOC

Göran Selander <goran.selander@ericsson.com> Thu, 24 January 2019 18:28 UTC

Return-Path: <goran.selander@ericsson.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 539DB131335 for <ace@ietfa.amsl.com>; Thu, 24 Jan 2019 10:28:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.874
X-Spam-Level:
X-Spam-Status: No, score=-7.874 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=cLzlWEpq; dkim=pass (1024-bit key) header.d=ericsson.com header.b=N6nomDtv
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 4mVUZouK_a3u for <ace@ietfa.amsl.com>; Thu, 24 Jan 2019 10:28:30 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1E3131331 for <ace@ietf.org>; Thu, 24 Jan 2019 10:28:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1548354508; x=1550946508; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gh8jsP56XY7BSESAuPuRaqxAri8bXFhPubRuilSIgNI=; b=cLzlWEpq3OZ+4U3hz3nuNUjem/it6hqdwdntq3bROJZduRTWRN97JKLFKZMOi6Fo /8mGs/gsqsT4jP+YmL85GPpZh3BcI0DSXX76iEePUZJXYEyI6N5CYR0ZKTDYG1cW E8KMDpjO25cO5IVDHq9Pfj39pihcFAUaIWixkszzYGU=;
X-AuditID: c1b4fb3a-5c9c29e00000672c-cd-5c4a03cc442c
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E0.CC.26412.CC30A4C5; Thu, 24 Jan 2019 19:28:28 +0100 (CET)
Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 24 Jan 2019 19:28:28 +0100
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 24 Jan 2019 19:28:27 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gh8jsP56XY7BSESAuPuRaqxAri8bXFhPubRuilSIgNI=; b=N6nomDtvPbAwOC32MGOPkt6GhBOHQfGGOOK9pgtUoM2ZROQUOv/kp8lBOdkwGbgVi5VfD93I4bEbAK8Msdn3Mpp6s97lnyjpy5YtMJ1NgSY2scnRKXC50TdKB/FoCSTa0mA4x8qk4gvKMF8QzJ25Cyper8+ed8xipKvAfrDg5Xs=
Received: from DB6PR07MB4167.eurprd07.prod.outlook.com (10.168.19.153) by DB6PR07MB3061.eurprd07.prod.outlook.com (10.170.222.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.10; Thu, 24 Jan 2019 18:28:27 +0000
Received: from DB6PR07MB4167.eurprd07.prod.outlook.com ([fe80::a10c:961e:8639:85f4]) by DB6PR07MB4167.eurprd07.prod.outlook.com ([fe80::a10c:961e:8639:85f4%4]) with mapi id 15.20.1580.004; Thu, 24 Jan 2019 18:28:12 +0000
From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= <goran.selander@ericsson.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: "secdispatch@ietf.org" <secdispatch@ietf.org>, John Mattsson <john.mattsson@ericsson.com>, Francesca Palombini <francesca.palombini@ericsson.com>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] [Secdispatch] EDHOC
Thread-Index: AQHUou5Zx1xiDx+jgESY4I5hUyszWqWcqBGAgAINKACAFqIAAIAACQQAgAmPyIA=
Date: Thu, 24 Jan 2019 18:28:12 +0000
Message-ID: <D06F172B-84EC-44AD-8E92-9E5EA98A806A@ericsson.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> <20190118172714.GJ81907@kduck.mit.edu>
In-Reply-To: <20190118172714.GJ81907@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.15.0.190115
x-originating-ip: [213.89.213.86]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB6PR07MB3061; 6:A/Z8INUXdubj2kIG6Wgh+/CT+a2Hduf50cuCeF29ygn2avct99j8tjZDYI0pFzkvgPF73Zo4zR/q+SCrB/lCCHf7biQy38hbfzkcMRk78v1ycybahKFwOA6fyJ5LrXnGITPYhWukiTKxrdjrW97swTCDZDKAgqDo+b+Z+O3QwZHyg/t4iEGq25f9/4Czstk1+4v1Bf282pUPCkjSH2d+NuB4VaIiwWcGoyrjTOrCXM+YwzNWQYafmhj1aG1Zd5q1RXR4omI+4/gBMhIRhkr9sjA1/YN4Ilj9HuEJCsaBeeRS1sYHc665WRL0wPVuQPU8atEzQhgN58XtMPFGLbwFJp0XBxc/RTnGKuXg47fr8WbaKx9nL769Uiw62zyCgwnoCYqVY0mK7SdMsG5CeS6Vmw/ia//sRA0Gk787caPKmnBTBssljlFZLJ9JxRLpavoFKdFN2GD2mTS7+4gDLQai0w==; 5:jJUDBUp/zwdGVEcU10x6gJOBEPL71BskKW/PXTXYqoWLX99pZ4FlanS0u7ciw4KDXrQY0DjFCbSqK8d3T+EZY9wg9DKkMUDnRZa73sSF6g494v3X8hrudBbaNPq4mPd3zZcXM9kkdo62oRxPQV1SiGMm1ORaZhwsMDTfbM1GJsZJY8jA23WSA2/FN1aw3yzIAfzeHtJ9LJEw+kh7wMPSMw==; 7:2gY7xKQu1oacRx2oxP9h/0jeKZ/2Dv9hVOOleudOOXSSydfROFGm9Yrpw7YBsmUQlHFUSEzs3mYdS6CzMw7IQB0vofsBloz98HuDXCUBVxlWQbrCojRHQfBy+/LjCpHYgTaXvABg9+FYYTFzK4JgwA==
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(376002)(39860400002)(136003)(366004)(396003)(346002)(189003)(199004)(68736007)(446003)(71190400001)(2616005)(476003)(11346002)(83716004)(105586002)(2906002)(26005)(6436002)(6246003)(102836004)(106356001)(85202003)(3846002)(6486002)(6116002)(76176011)(6506007)(82746002)(2171002)(33656002)(97736004)(66574012)(186003)(4326008)(36756003)(229853002)(478600001)(486006)(305945005)(8676002)(14454004)(256004)(99286004)(8936002)(53936002)(6512007)(14444005)(85182001)(25786009)(58126008)(316002)(66066001)(81166006)(7736002)(81156014)(93886005)(54906003)(71200400001)(86362001)(6306002)(966005)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR07MB3061; H:DB6PR07MB4167.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-office365-filtering-correlation-id: 99dff6e8-ea6e-4b26-fec3-08d68229b2ca
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:DB6PR07MB3061;
x-ms-traffictypediagnostic: DB6PR07MB3061:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com;
x-microsoft-antispam-prvs: <DB6PR07MB3061CB5366C3000DE661231DF49A0@DB6PR07MB3061.eurprd07.prod.outlook.com>
x-forefront-prvs: 0927AA37C7
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: oxFk5wOgg2+Pyiou9Yo7O6SXeEO6IM96CyjaMIWMks8rm9FRWssp3i8IUMw8LoBe56VAuRj2XfMyZlNf6dYu9tPk57/W9oxFZjzDDc60zkLpeMZiGQdcheWwzElKH+RaA+Tjcbv94xT9LDJqzCLazIysGU1zbkC+cmA27DaPR9W1Oijqo+9lVu3XpkmnVrh/+UBfczNzT4hlQGtyui6qSDpkgpBUzUS2NciU+3miK/Hx/cmk0aZFTOl9AYHTxZjC051ztjCmgctbbeCC/3iGvtCWi0JHRIPEvlOFGwIsaYqtwjOk9TlGR56UugZfwx5uJ3KI5UpHKDjpAOyZr5LytKy6/pEhYJva80MvxWf6KV+8cXls79hWNWsovNTSegQtoLOYNlSdZc2tESPEd8Dt5JkKAfsK0nv+Nkbb3DyaSdw=
Content-Type: text/plain; charset="utf-8"
Content-ID: <A8E1BA2DCC688E47B487353D8E0E1F39@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 99dff6e8-ea6e-4b26-fec3-08d68229b2ca
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2019 18:28:12.3210 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3061
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SaUhUURSAue+9eT6HJq4vxzlugZMpGmqO/ZBQW8zQzJCk0BjTQR8qrrxn LkE6TZsbamiWIhipWSktKioVqJMiheaSmfnDcqG0lKjMHcmZN0H/vnO+c+8553IZkq2Q2DAJ Kekcn6JJUtJSqjK8PdOtnzyh3l88ae29slxEejc8qyS8m8Y+SA6TgXV1a0Sgrr+XDCXOSX1i uaSEDI738IuWxnct7U7b9M0qXsmnteipTwEyZwAfgPX2SlSApAyLexB8WWglxGAZQYNumBSD OgImrw4aDYVLSZhtr6dFU0bAvaUh2nAZi6cRlMxFG5jGx+CzdpowsCVWQu3AVeMBEncgmHw3 RhnELuwEutF+SixyhvsLtbTIp0Db8N7MwBTeC21b+dtzMIwMH4LbQyFi48sEDDxYQ4Yac+wF 478mjYywFay8aTI2JrECJmZrCHFTDHUvB0mR5TA/syUxsBx7wLWVVYmYd4BpfYmJ7WGkptD4 MoB1ZvCpoosShSf0PewkRVFDw5+en2aiCIGZ3iLT6Y8I1ovOiOwK+vEu03TnQfdYS4v5RNA1 T9ClyKPqv2GrthclsQs8eW5KB8KtlmoksgOUF06ZGViGLeB15Sx1F0keIbnACUJynErlzvEJ MYKQmuKewqU3o+3f0t26cbADdX89okeYQcodst7lIDUr0WQI2cl6BAyptJQFDB9Xs7JYTfZF jk+N4i8kcYIe2TKUUiHbZC3ULI7TpHOJHJfG8f8swZjbaFGkf+Cio7XL77BLzSOrmjxFpxfh 1VIeMevUNlHbo/XjN+behm+GnXTGoTnB1+cDggUXtz3tvFVPdKO2mrCWhgmKGzFHX+yMstxn nzs+5au5aVdUtpA3GjRe3/k901OmdHCMtMtRsGdVS2SNf0TOads7P2YW+7LkqisdufOvvjUq KSFe4+lK8oLmL43yhvEpAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/iztgMst-2F1-ENOT6P26NQxJg-8>
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: Thu, 24 Jan 2019 18:28:32 -0000

Hi Ben,

I replied to some of your comments in my previous mail to the list. Additional comments inline.

On 2019-01-18, 18:27, "Benjamin Kaduk" <kaduk@mit.edu> wrote:

    On Fri, Jan 18, 2019 at 11:54:58AM -0500, Richard Barnes 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.
    
    ACE's charter is ... messy.  More below.
    
    > 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).
    
    
    There seem to be several interleaved issues at play, here, and I agree that
    some clear/consolidated background would be helpful.  I particularly call
    out the security proof that has been presented elsewhere, which I think
    would be interesting to several readers (but I don't have the link handy).
    
Referenced in Roman's previous mail to secdispatch. I agree that asserting the formal security properties is key.

    Some thoughts of my own...
    
    There is clear demand for a lightweight key-exchange protocol for use in
    IoT protocols, especially OSCORE.  EDHOC has been around for a while, and
    even discussed in ACE with some frequency.  That said, there are several
    reasons to prefer asking secdispatch to just calling for adoption in ACE
    directly, including but not limited to:
    
    (a) designing secure authenticated key exchange protocols is hard!  It takes
    a lot of energy from smart people to design and analyze a protocol to have
    confidence that it is secure and fulfils the advertised functions.
    Starting from well-known/well-analyzed foundations like SIGMA is a great
    start, but hardly a guarantee of success.  Secdispatch gets us some better
    visibility, and insight into where work can be done that will have
    sufficient expertise (both within and outside the IETF, as well as what has
    been done already vs. what remains to be done) to be confident in the
    result.
    
This sounds like an excellent support function. Thanks.

    (b) ACE has a pretty complicated charter, that seems to place restrictions
    on how it can adopt new protocol work without rechartering.  We find things
    in the charter like "existing authentication and authorization protocols
    will be evaluated and used where applicable [...].  Some functionality,
    however, may not be available in existing protocols, in which case the
    solution may involve new protocol work."  This would seem to require a
    clear criteria for how to determine whether or not existing technology is
    applicable, plus evidence that existing protocols do not meet the bar.  In
    particular, "make the key exchange messages as small as possible" is not a
    clear criterion, as that would always argue for a new protocol over an
    existing one, as we come up with new ways to eke out space.

I don't know how important it is to fit into the existing ACE charter but the comparison between EDHOC and TLS/DTLS handshake showed a reduction in message overhead with up to 75%, which can be translated into power consumption. I would say that "power efficient key exchange" is functionality not available in the existing protocols we looked at.

    (c) A clear and substantial difference between key exchange/handshake size
    between EDHOC and even minimized DLTS could be compelling enough for
    secdispatch to decide that the work is usable, and find an appropriate
    home, independently of the question of rechartering ACE and meeting the
    additional barrier described in the previous point.
    
The WG is not crucial, but involvement from the user community is valuable as well as the security expertise. 
    
    Jim and several others have done some good work looking into tabulating
    message overheads in various scenarios (e.g.,
    https://www.diva-portal.org/smash/get/diva2:1156483/FULLTEXT01.pdf,
    https://jimsch.github.io/randomDrafts/draft-schaad-ace-tls-cbor-handshake.html)
    that will be helpful as we consider this topic.
    
    In addition to just comparing the byte count for handshake/key exhchange
    messages in various methods, it would probably also be good to think about
    things in terms of the constraints in the current ACE charter.  That is,
    someone could (1) pick a (class of) device(s), (2) show that it has wide
    deployment/potential thereof, (3) give hard numbers about what it's (not)
    capable of, and (4) show that DTLS falls on the wrong side of that cutoff,
    using the handshake numbers we already have.  In particular, I don't
    remember seeing anything touching on (3), previously.  An analysis like
    this would not only give some context for interpreting the gap between
    EDHOC and DLTS, but could also be compelling in support of the need for the
    more lightweight solution.

As mentioned, message overhead differences translate into measurable quantities. While it may be possible to find an example where there is a clear cut, I think for many scenarios there would be qualitative differences.

Göran