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

"Valery Smyslov" <smyslov.ietf@gmail.com> Tue, 19 February 2019 10:13 UTC

Return-Path: <smyslov.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 DA5AF130E96; Tue, 19 Feb 2019 02:13:02 -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, 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 HlXkTjkH-oob; Tue, 19 Feb 2019 02:13:00 -0800 (PST)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 01165129284; Tue, 19 Feb 2019 02:12:59 -0800 (PST)
Received: by mail-lj1-x22e.google.com with SMTP id g80so16910877ljg.6; Tue, 19 Feb 2019 02:12:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=dgtOGpgZbu0jUI3mRJMFGXbJpflh40OU0SOvShB5ZfE=; b=cSQfahDIMh6YgJw1JdeF/w3VezE4z34d4FdPCTkIYe+1GuagRmR1NBZf0PIsJVoZKk vN3tzjHjhMA32og6N4b5tWCmwSN7nYDTO91rUK0a6E89Xff4/SddYJH478bVEmBaEMeP eDKMGED1uJla/g45gyoqr4CikVRMA3DGg9BLw4+uc6zP+YPCighaMHwIQb+m9wJmaO+F Wlw/D+5nZACCN2O0wTXXpFo/SPPJM8rZFVLuQWw2N7yUSJrbjz/bazs9xDolEkKuamiZ YTmI1NtgMscFiTTKS/rE3FdbHUWYlycFdKxLxOffXHnt0s+IuMoEXwnwyHRm2HHJVv9k nNxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=dgtOGpgZbu0jUI3mRJMFGXbJpflh40OU0SOvShB5ZfE=; b=cVCXKRFoAT/HJCihsRhNUONFIVTL2D8MuCzqp1dto/UmZZwzciWyKcJ8jvyVfD0RAW JFLiBVmVwZAb9NRKfO3rcCK2Yd82K7WX5MeKpmpy91C3yCP//P9kOvnxrax7UQGfQEAc QjvvMZQOnBFN19i1RqsyCKSSdnOM9WrEU8A9PfebDRgVi4IMuBr9Raa3VFy5/4qdLarP +XZEyTTuyAHomrbFnHnGrRsfi/zY6c+VJIKo7TVOa1owHg+p1KEW47WCJiXhWNPajfxe Q9CvKDWb9gXB+e4SSAIys+UZU9YF46cuL0v7j8CtA/15CEZ0c2IUC53WnYlLoNk7iz+r qpyQ==
X-Gm-Message-State: AHQUAuZcDJDs8fNilznaeW+okEloAc6/eghz84nd7VV2WSSWPtceqXlx sfWgqGpVbuG6iE6gts1nghYDj68D
X-Google-Smtp-Source: AHgI3IbDhAzBAsO3umWNjUN7p7nGacyMexn79khPczzBY8PgJuiYlOSM+T9fvDvDTiQ/bAcCeGN3XA==
X-Received: by 2002:a2e:91c8:: with SMTP id u8mr16069889ljg.185.1550571177805; Tue, 19 Feb 2019 02:12:57 -0800 (PST)
Received: from svannotebook ([193.16.208.3]) by smtp.gmail.com with ESMTPSA id z8sm4473096lfg.77.2019.02.19.02.12.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Feb 2019 02:12:56 -0800 (PST)
From: "Valery Smyslov" <smyslov.ietf@gmail.com>
To: =?UTF-8?Q?'G=C3=B6ran_Selander'?= <goran.selander@ericsson.com>
Cc: <secdispatch@ietf.org>, <ace@ietf.org>
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>
In-Reply-To: <2F99BE31-7193-4DE8-9509-4902EA8E4EBE@ericsson.com>
Date: Tue, 19 Feb 2019 13:12:41 +0300
Message-ID: <010a01d4c83b$a75b6f40$f6124dc0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGUr/RRE8LCsN9xtsl6weR5tpA+UAIeiej4AoQBM8oCW2amOQMoEywnATA688wCvmGpV6X2bE1Q
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/L2091np8oe9VOR03Axh0IPhRK60>
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 10:13:03 -0000

Hi Göran,

> 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,
because it is he who initiates secure connection with responder). If this third
message is lost or the packets are reordered, then the responder will start receiving
encrypted data from the peer he hasn't authenticated yet. The responder in this
case has two options - either discard incoming encrypted data or buffer it in hope
that the last EDHOC message will come shortly. Both alternatives are bad - 
either it impacts application protocol or opens surface for DoS attack.
Note, that from the initiator's point of view everything is fine, the protocol
has completed successfully, so in general the problem cannot be solved by
sending retransmissions by initiator, instead, the responder must become
an active retransmitter in this case and re-send the second message to nudge
the initiator to re-send the third. This was discussed in the ipsecme WG when
IKEv2 was being designed (back to 2003-2005).

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

Note also, that lacking the fourth message there is no way for the responder
to report any authentication error back to the initiator...

Regards,
Valery.

> Thanks,
> Göran
>