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

"Valery Smyslov" <> Mon, 18 February 2019 07:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E6841276D0; Sun, 17 Feb 2019 23:07:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Status: No, score=-0.499 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, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P2xVBzLsIvPP; Sun, 17 Feb 2019 23:07:09 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD96C1228B7; Sun, 17 Feb 2019 23:07:08 -0800 (PST)
Received: by with SMTP id u21so11493449lfu.1; Sun, 17 Feb 2019 23:07:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=ZBc2JiGCY8yBztskJre/C1m9U+98qbX36XWZs0IFNf4=; b=Y2YftUtOxyZdvlc+Ar6ecgEIkAQVgOOtwSfhfYxwh4ZM6q2b8abhLkupDOY+qKmEoq ThJ4c2YfGEnNSNykvsXAD/AmetzwB+9PyfuvjyC+yeb+3lpmkn5UAwG9Y1TBLXU47sko kBqYeTLR5i6e/98nIDzpXP9C0YoCPWJd8JcKxkui+c6mPOyM4gbwAYdgofWPtNy5VQOu njAt1I6W5NEeiEbKlw9MAnOHPpLjQqvV06XE7a1N11cabrjAS3BHOD/WQVELftCH4HHm v2ecVMVshAUgskJIptwlmZoMqrqQ367fk/LKgdvKIMvEyFPymYt7zZ9O4yMSqQNfiCgf aGqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=ZBc2JiGCY8yBztskJre/C1m9U+98qbX36XWZs0IFNf4=; b=FjG6bTLGXYeC7DEMN0zjRDwR+jiPu5yJB067D92sN2DIowYjtPMeRWP4T9WFYl5zGm Tt2REdi+XEgws7dcv0Qw9GIKwjrCv8hOnw6xRMQYYWj1BHv9GxYR+/FiqSEwNHv2TMK7 q08JsOtCDvCKa8z4UHVCRL5SuF5f5phko/m5Dp3fGV1BgyJQ7eCnfS1ZK7v6WbelDWX3 YfenOVf7K6ZDr/AsDyQ5kOZexE1jUm1QtqvATOwrepRJrYCqxkaLOn1fC0A4P53z4ku5 DMSgE4mDTwDL4rsKjarz2KrDyLmboTqMmYfjOu72JQjWFQ4qcnN2BW3vAWYAvPH06yco x9gA==
X-Gm-Message-State: AHQUAuZgMBSd9ibBVs8zz4tu7am2OqEvOW1R/MmS9h7W1w0dzPpKEx5A LXmoNYfoZjlOCMLfoB0//Eqlu1B7
X-Google-Smtp-Source: AHgI3IY+dwUaEuC3ymZ2sB0Npjt4x8Bavs2bZzl1Yxss6uulGBje7ZBVZ0hEemG9UhQ5K+fPKh5LrA==
X-Received: by 2002:a19:6e0b:: with SMTP id j11mr12642970lfc.124.1550473626606; Sun, 17 Feb 2019 23:07:06 -0800 (PST)
Received: from buildpc ([]) by with ESMTPSA id l72sm3546875lfg.75.2019. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 17 Feb 2019 23:07:05 -0800 (PST)
From: "Valery Smyslov" <>
To: "'Michael Richardson'" <>, "'Richard Barnes'" <>
Cc: '=?UTF-8?Q?G=C3=B6ran_Selander?=' <>, <>, <>
References: <> <> <> <> <12390.1550453705@localhost>
In-Reply-To: <12390.1550453705@localhost>
Date: Mon, 18 Feb 2019 10:07:05 +0300
Message-ID: <01f601d4c758$8e9d25e0$abd771a0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGUr/RRE8LCsN9xtsl6weR5tpA+UAIeiej4AoQBM8oCW2amOQMoEywnphQcPCA=
Content-Language: ru
Archived-At: <>
Subject: Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Feb 2019 07:07:10 -0000


> Richard Barnes <> wrote:
>     > Finally, to be totally honest, I find the EDHOC spec pretty inscrutable. A
>     > little more prose to explain what's going on would go a long way toward
>     > helping this discussion be productive.
> Sure.
> Find a WG to adopt it, and we can make the text beautiful.
> The packets are all there, and the references pretty much explain all the crypto.
> This stuff is not any newer than IKEv2.

I have only a quick look over the draft, but one thing strikes me - the protocol 
is claimed not to bound to a particular transport (so I assume that implementing
it on top of pure UDP is fine), and it has an odd number of messages.
That's OK from cryptographic point of view, but it's a headache for 
implementations if the transport protocol is unreliable, since in this case retransmissions 
must be sent by both parties. We learned this lesson from IKEv1 (Aggressive and Quick modes) 
and in IKEv2 the number of messages in any exchange is always even, 
that simplifies implementations and makes protocol more reliable.
Of course if only reliable transports are considered, then this doesn't matter.

Valery Smyslov.