Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 19 February 2019 16:01 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 79D3F130F0F; Tue, 19 Feb 2019 08:01:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 8xXj0XeQWz9d; Tue, 19 Feb 2019 08:01:14 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88FAB130F0E; Tue, 19 Feb 2019 08:01:14 -0800 (PST)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 586A338263; Tue, 19 Feb 2019 11:01:06 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 2684A2687; Tue, 19 Feb 2019 11:01:12 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 24949265F; Tue, 19 Feb 2019 11:01:12 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Valery Smyslov" <smyslov.ietf@gmail.com>
cc: =?us-ascii?Q?=3D=3FUTF-8=3FQ=3F'G=3DC3=3DB6ran=5FSelander'=3F=3D?= <goran.selander@ericsson.com>, secdispatch@ietf.org, ace@ietf.org
In-Reply-To: <010a01d4c83b$a75b6f40$f6124dc0$@gmail.com>
References: <4FA72889-F601-4255-962E-9A13E932EE21@ericsson.com> <CAL02cgTM93+ij+ottP_xR+OTvdj3S+pCKNOAAjEsj8Srt7EeYA@mail.gmail.com> <998ABFEF-7E5B-4B91-80DB-20ED43DE9A5C@ericsson.com> <CAL02cgQFyB4YOMr=hDdTVQ6Vc8LFo+RxVB9JA2EucdRK8_-wbA@mail.gmail.com> <12390.1550453705@localhost> <01f601d4c758$8e9d25e0$abd771a0$@gmail.com> <2F99BE31-7193-4DE8-9509-4902EA8E4EBE@ericsson.com> <010a01d4c83b$a75b6f40$f6124dc0$@gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Tue, 19 Feb 2019 11:01:12 -0500
Message-ID: <21416.1550592072@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/e80Z23yczHpypnTJ0fyenkSgEPM>
Subject: Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports
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: Tue, 19 Feb 2019 16:01:18 -0000

Valery Smyslov <smyslov.ietf@gmail.com> wrote:
    >> Current version of EDHOC is 3-pass to allow traffic data after one round trip,
    >> which reduces latency in many applications.
    >> A 4-pass version has also been discussed:
    >> https://mailarchive.ietf.org/arch/msg/ace/ZDHYEhvI0PenU6nGrhGlULIz0oQ
    >>
    >> When EDHOC is used as key exchange for OSCORE, and also in other settings,
    >> EDHOC will commonly run on top of CoAP. For example, in 6tisch the join
    >> protocol relies on CoAP proxy functionality. CoAP is defined for reliable
    >> transport (RFC 8323) as well as UDP (RFC 7252), the latter handles
    >> retransmissions by client and server. An example of using EDHOC with CoAP is
    >> given in appendix D.1:
    >> https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-11#appendix-D.1
    >>
    >> It sounds like we should add some considerations for the setting you outline.
    >> Do you have an example or pointer explaining the specific problem in more
    >> detail?

    > In the current EDHOC draft the initiators sends the last (third) message of AKE and then
    > immediately starts sending encrypted data (note, that he has almost
    > always something to send,

When done over CoAP, the message would be sent with CONfirmable, so it would
be ACK'ed.  I would make the first message CONfirmable too.

That makes it much like IKEv2 is, where all messages are ACKed and the initiator
is responsible for all retransmits.

If someone wants to run EDHOC over another transport, then they would need to take this
into account.

    > So, unless you rely on a reliable transport that preserves packets ordering,
    > having odd number of messages significantly complicates implementations.

CoAP is reliable, and it does preserve packet ordering if asked to.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-