Re: [Ace] [Secdispatch] EDHOC

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Mon, 04 February 2019 17:31 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 226A7130E86; Mon, 4 Feb 2019 09:31:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 wKDsgSoSGW6k; Mon, 4 Feb 2019 09:31:00 -0800 (PST)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 0754D12426A; Mon, 4 Feb 2019 09:31:00 -0800 (PST)
Received: by mail-ot1-x329.google.com with SMTP id w25so1043504otm.13; Mon, 04 Feb 2019 09:30:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eT+XxSHyTUPHlRo+uhKEsykIIYBHjf2B2+idUA/sMMc=; b=Fwb/fjFQ6UutiWgkSnrvImJ2HZlZVxm76MRmcrjIu2WDJK64c4kyk/NimCqsT5Q64R A0Hhc98X/ccGG1A0FDXNF/V+qL/E135zCGtxcYi94uJuwl3yWcIEZJ+ROeicq8h3AqTN /lYxAoiahZiY48PQzlPTd2pJJUddN5K0KUF7voY1doyFAYfvkfEnA9IPKgsdVn/sBJA1 VFv6pdPqnRtBom3WyRkAhrr2z88j60Gz4tKY6Bo4HgOxc8leIyK15HxArXTRs94vE7K4 ftKSGV7tcmgovGjW7vOsQley0ZXDY7HL3pJ55B6aoGbbIWYb9hJQNfEUec/gY4jNEsnk HSQA==
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=eT+XxSHyTUPHlRo+uhKEsykIIYBHjf2B2+idUA/sMMc=; b=s3xQUscTwzM7iLgET4DCrLOLGKkOFTjIbZUBqG9BZJHt+YWsavmBQkE15iFmGIqhda 7Rb0mb4uj9WR+58PxYz8AG1WYJ+Wg7JjdGXXRi1oeGmqY41F1e6EE6rrDZHyVZL9w4Mh TEuRpyN3qkte1WC2p9jl5R0+CD9+tkYexYTR1SidFgB7XWd7Ol22X9mN1HAX+ufPOqSn Q37LC5KZUC4DZyqHzRCDkZuicbGIWVNmfjuM8gXGMe9zOaTdH22hyvRPCoD7CN75wxzF t+s4BhqComMaZ73yZNt8i3vxj7inmLX04Ip93vnPZ92rqGaKN6HnzFw7yfg2CSwquQ8J fhsw==
X-Gm-Message-State: AHQUAuZnophKDgV0oOEOwpF2+7oOVh6Mf0Y4+pbYGzac0F7wVkZ5z5QY 6sCjx/FSIXvERQiHG6FCqfWP97p4R8l3axXyzi0=
X-Google-Smtp-Source: AHgI3IaIGehYAnSgKlz1UzMoeWf6iLDXnUB4wEimELuNzeHzJxjqg0J1HASVMcFNIn1PLW5Ckwesl5OuxD6gMnJz8ZU=
X-Received: by 2002:aca:544:: with SMTP id 65mr248962oif.302.1549301459225; Mon, 04 Feb 2019 09:30:59 -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> <20190118172714.GJ81907@kduck.mit.edu> <359EC4B99E040048A7131E0F4E113AFC0185795C45@marathon> <CAL02cgQgoxrxzBHk9pCvWwg8n91gpfK=4kReGfFfb=Av8=CoCw@mail.gmail.com> <05C8AB73-EFD1-4AC8-A795-D3624153F4D2@ericsson.com> <CAHbuEH4JpZV9TeCFjv89oCeQLD21rPdkbjKeLnRPG1V07VCRBQ@mail.gmail.com>
In-Reply-To: <CAHbuEH4JpZV9TeCFjv89oCeQLD21rPdkbjKeLnRPG1V07VCRBQ@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Mon, 4 Feb 2019 12:30:20 -0500
Message-ID: <CAHbuEH6MpTowqTFmFejr0xi6a8+SarHjfifMHjP=Vf+if49RXQ@mail.gmail.com>
To: =?UTF-8?Q?G=C3=B6ran_Selander?= <goran.selander@ericsson.com>
Cc: Richard Barnes <rlb@ipv.sx>, Roman Danyliw <rdd@cert.org>, John Mattsson <john.mattsson@ericsson.com>, "secdispatch@ietf.org" <secdispatch@ietf.org>, Francesca Palombini <francesca.palombini@ericsson.com>, "ace@ietf.org" <ace@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000209449058114db1c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/g8oEhlh1Fub-CmOkITUbesjG8gw>
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: Mon, 04 Feb 2019 17:31:03 -0000

Will there be an interim for this topic?

Thank you,
Kathleen

On Thu, Jan 24, 2019 at 2:15 PM Kathleen Moriarty <
kathleen.moriarty.ietf@gmail.com> wrote:

> Thanks for the very helpful message, Goran.  A couple of comments inline.
>
> On Thu, Jan 24, 2019 at 11:31 AM Göran Selander <
> goran.selander@ericsson.com> wrote:
>
>> Hi Richard, Roman, all
>>
>>
>>
>> Thanks for kind welcome and for progressing the discussion. Apologies for
>> a long email.
>>
>>
>>
>> *From: *Richard Barnes <rlb@ipv.sx>
>>
>>
>>
>> Summing up where I believe the conversation stands now, it seems like
>> what folks are asking for is either:
>>
>>
>>
>>    1. An analysis that shows that EDHOC is equivalent to an existing AKE
>>    (e.g., IKE or TLS), or
>>
>>
>>
>> 2. An argument that a new AKE is necessary (vs. a re-encoding of an
>> existing AKE)
>>
>>
>>
>> Göran et al: Do you have thoughts on those points?
>>
>>
>>
>> Yes. I’ll get back to this later in this email.
>>
>>
>>
>> It seems like it could be a productive use of an hour or two of virtual
>> interim time to help the group understand one of those lines of argument.
>>
>>
>>
>> Agree.
>>
>
> Anything to prevent further hold ups on this work would be appreciated.
>
>
>>
>>
>> --Richard
>>
>>
>>
>> As requested in a previous email, here is a background.
>>
>>
>>
>> The work on EDHOC is motivated by the need for an authentication and key
>> exchange protocol for OSCORE (draft-ietf-core-object-security) optimized
>> for constrained-node networks (RFC 7228). OSCORE is applied within the
>> IETF, e.g. in 6TiSCH minimal security (draft-ietf-6tisch-minimal-security),
>> but also requested by other SDOs and industry fora such as OMA Specworks,
>> Open Connectivity Foundation and Fairhair Alliance. The properties of
>> OSCORE motivating its use include: support for CoAP forward proxies,
>> support for change of underlying transports including non-IP, low overhead,
>> low additional footprint and memory to existing CoAP implementations,
>> support for multicast security, security for end-to-end REST.
>>
>>
>>
>> Given the large interest in OSCORE already before it has become an RFC we
>> anticipate a wide range of deployments. For example, we see an interest for
>> OSCORE in Cellular IoT with traffic running over the cellular air interface
>> control channel, where we can have end-to-end CoAP, but not necessarily
>> end-to-end IP between an application server and a cellular device. Or
>> between an application server and a device behind a cellular gateway.
>> Comparing just these two cases, the difference in capabilities of the
>> devices can be significant which makes it difficult to point at some sort
>> of “reference devices” for benchmarking.
>>
>>
>>
>> In order to support the low end use cases the AKE must be performant in
>> low bandwidth deployments with battery powered devices restricted in RAM
>> and ROM. Message sizes and round trips have a direct impact on latency,
>> power consumption and battery lifetime, and can be calculated which is the
>> reason for this being a commonly used metric. While it may be more
>> difficult to compare memory and storage requirements, the ability to reuse
>> existing code is an important indication. If a device can support a CoAP
>> stack (in the sense of memory and flash, etc) it is expected to also be
>> able to support OSCORE. Similarly, it is desirable that a device with CoAP
>> and OSCORE implemented should be able to support an additional AKE.
>> Considering that EDHOC reuses CBOR and COSE primitives from OSCORE the
>> additional code for EDHOC can be very limited.
>>
>>
>>
>> From a security point of view OSCORE requires that the endpoints have
>> agreed on a Master Secret with a good amount of randomness, and each
>> other’s Sender IDs, and those must be different for a given Master Secret.
>>
>>
>>
>> Now returning to the questions.
>>
>>
>>
>>    1. An analysis that shows that EDHOC is equivalent to an existing AKE
>>    (e.g., IKE or TLS)
>>
>>
>>
>> Considering EDHOC is a new protocol it should be thoroughly analysed and
>> verified against all currently known issues of AKEs. Roman sent a mail to
>> the secdispatch list referencing a paper presented at SSR 2018 which could
>> be used as a starting point. How do folks want to digest this: Do they want
>> to study the model themselves or should we ask the authors if they could
>> present their work at the interim?
>>
>>
>>
>> 2. An argument that a new AKE is necessary (vs. a re-encoding of an
>> existing AKE)
>>
>>
>>
>> We have done this comparison with TLS/DTLS for some time now, and what
>> once seemed like a reasonable question has turned out to be never ending
>> exercise. I do not want to get into IETF archeology but for those who have
>> not followed the discussion some data points could be relevant.
>>
>>
>>
>> Not long ago, the design of security protocols did not take into account
>> constrained IoT devices. With OSCORE we showed that the message overhead
>> could be reduced by a factor 3 compared to DTLS 1.2 records. Before this
>> comparison it was believed that the record layer was performing well, then
>> the difference in overhead was characterized as insignificant, and then
>> finally a compact format was designed for DTLS 1.3.
>>
>>
>>
>> With EDHOC we showed that the message overhead of the key exchange can be
>> reduced with up to a factor 4 compared to the current version of DTLS 1.3
>> (see Appendix E in EDHOC). Before this exercise it was believed that the
>> TLS/DTLS handshake was performing well, then the difference in overhead was
>> characterized as insignificant, and now the discussion has shifted to
>> downsizing the TLS handshake or other protocol.
>>
>>
>>
>> We are not against optimizations to the TLS handshake, just as we welcome
>> the more optimal DTLS 1.3 records. But TLS was not designed to be an AKE
>> for OSCORE optimized for constrained environments. As I remember,
>> optimizing for message overhead was an explicit non-requirement of TLS 1.3.
>> Reverting those design decisions seems like the wrong way to go: One reason
>> to use TLS would be to reuse an existing implementation. But existing TLS
>> implementation would most likely not compare favorably in terms of code
>> size and RAM. Adding code for compression or re-encoding of the messages
>> would add to that. Re-specifying the protocol with the new encoding may
>> require a new formal verification. To make a more compact code and
>> processing may involve two incompatible message formats of TLS depending on
>> what is being signed. New implementations would be needed.
>>
>>
>>
>> We think we have done our part of the comparison exercise and that the
>> burden of proof should now be reversed. Could we ask those that claim to
>> have a more performant key exchange protocol for OSCORE and are prepared to
>> do the work to make that plausible and provide the numbers? To be clear: if
>> there is another key exchange protocol suitable for OSCORE which
>> outperforms EDHOC in constrained characteristics and then we are very
>> interested.
>>
>
> I agree with Goran that they have jumped through enough hoops at this
> point.  However, if alternatives come forward, understanding their
> timelines is also critical as not to hold up this work for any substantial
> amount of time.
>
>
>>
>> And again, with the statements in this mail we neither want to belittle
>> the considerable effort made on formal verification, nor claim that DTLS is
>> not fit for IoT deployments. It is an important hammer in our IoT security
>> toolbox, but at the moment we don’t need a hammer.
>>
>
> The class of IoT device seems to be the critical point here and having one
> protocol that can meet all needs is a nice goal, but not realistic from the
> comparison numbers provided and the varying requirements in the IoT space.
>
> Best regards,
> Kathleen
>
>
>>
>>
>>
>> Göran
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Ace mailing list
>> Ace@ietf.org
>> https://www.ietf.org/mailman/listinfo/ace
>>
>
>
> --
>
> Best regards,
> Kathleen
>


-- 

Best regards,
Kathleen