Re: [Emu] FW: New Version Notification for draft-ingles-eap-edhoc-05.txt

Alexander Clouter <alex+ietf@coremem.com> Tue, 07 November 2023 17:04 UTC

Return-Path: <alex+ietf@coremem.com>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC81C16F40E for <emu@ietfa.amsl.com>; Tue, 7 Nov 2023 09:04:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=coremem.com header.b="FXi95KKJ"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="GDEDjjsz"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 710_ehdGO6Ti for <emu@ietfa.amsl.com>; Tue, 7 Nov 2023 09:04:09 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21108C17C89E for <emu@ietf.org>; Tue, 7 Nov 2023 09:04:08 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4EE2C5C00C5; Tue, 7 Nov 2023 12:04:06 -0500 (EST)
Received: from imap46 ([10.202.2.96]) by compute3.internal (MEProxy); Tue, 07 Nov 2023 12:04:06 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coremem.com; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1699376646; x=1699463046; bh=AO pHLfUxpRdEQa09E/dh7mSDhNf+F5LM81GQgAq6vzo=; b=FXi95KKJzystbGvtD9 Js6MCNRN1JQD8dKX5o7LaVslE0EAlAunegCx+BwKTlXd/CznJxXu6IhCK+IaEZKk dCiHrjMtERgbFArsobuI6qzMmQ2y+47aEMPVT8RlJvFpKxd5ozYbNask01cfCrUi gs84nYnUW97975bP+23/jx4knmUtJPoC1Vh8mbb7WLevKxcZPiRoLqGVQx6tBi3c o9+du0zLZ+8gyn2Rm86+C5cDEX4EP8n6x/umDm2J+AGvhM9f29NA+rDv/LOzAGnU Wxy2+pk88Sb+1zl/xf1T0gRTRwia9j5fUCtJ1Ey2X8VyVXe0PUt3W+IjeW+e8QAt mJGA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1699376646; x=1699463046; bh=AOpHLfUxpRdEQ a09E/dh7mSDhNf+F5LM81GQgAq6vzo=; b=GDEDjjszqwaDjQbqsGyaiWhB+Aa67 KemPDwK3un+p1HhufgSGv5i6L3gr32ti9vbkyZRxNJ1FulIwOxHAIMOdmJGqsLzY VZbvymyRQ/30iABGqSDqmh8L0FGyr6cm0zU+fkZcMCLifUOjZschSA/q8yPNfCF9 wJGICdIcalWiWsUXNN6nlJw0okG2ID/MiPl9VSyk2m1LTktyXfKl5AfCzmndKLsT wELnWFuBD1iTQScdVyCXEEKoZ/rdXQhTacJQq4z0nhbX2W4iY6bAknSwju742S4V dDG4EpZm1pdQKCvSajIynSEfXZP1SNbgf4XBI8n1Qe1tRiIJlmq/QA9fQ==
X-ME-Sender: <xms:BW5KZTMOuoKmG2rJ5ugb0nHm5uDcHoniudhVFwEsr4mmkpX6PE4i8A> <xme:BW5KZd_582p9Dk-Qkvm-uyNqSIAkaCgOqzGypRPm1IDSLlePMrTow-j4j_8ZxKcvc pUgHQDTGxtlB8Kljw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddujedgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehl vgigrghnuggvrhcuvehlohhuthgvrhdfuceorghlvgigodhivghtfhestghorhgvmhgvmh drtghomheqnecuggftrfgrthhtvghrnhepgeefhfdvleeghfekhfdvhfekffffieeugeei vedvudehgfeufffhhfetgeetgfetnecuffhomhgrihhnpehgihhthhhusgdrtghomhenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhgvgido ihgvthhfsegtohhrvghmvghmrdgtohhm
X-ME-Proxy: <xmx:BW5KZSQWVG-AKT0NudKKMo33OpjrjbdQkIRZ7VmZeTJyjQElJP_LuQ> <xmx:BW5KZXsxxdhnX2KaUHGMyc84ubF1UN0-XgkojGghIL5uFp4Xt6U4qg> <xmx:BW5KZbdXEvq_2UF2EVu2P3CDdZ_7iiUxYgjzHhVnbSTLeKAZNsEm8Q> <xmx:Bm5KZZrpo19v82jEl6GwDTOg77tIeoFbweQ4q2TLS3MYRP8uhnBSaw>
Feedback-ID: ie3614602:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id C8CAA2A20085; Tue, 7 Nov 2023 12:04:05 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1108-g3a29173c6d-fm-20231031.005-g3a29173c
MIME-Version: 1.0
Message-Id: <2fa072aa-85a5-4903-994c-c43359f9c604@app.fastmail.com>
In-Reply-To: <GVXPR07MB96788859323504248877159F89C1A@GVXPR07MB9678.eurprd07.prod.outlook.com>
References: <169450647537.58011.6980212842488331191@ietfa.amsl.com> <GVXPR07MB96788859323504248877159F89C1A@GVXPR07MB9678.eurprd07.prod.outlook.com>
Date: Tue, 07 Nov 2023 18:03:44 +0100
From: Alexander Clouter <alex+ietf@coremem.com>
To: John Mattsson <john.mattsson@ericsson.com>
Cc: EMU WG <emu@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/RrttnQjxw_DZk26z4f_W9xnDTTk>
Subject: Re: [Emu] FW: New Version Notification for draft-ingles-eap-edhoc-05.txt
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2023 17:04:14 -0000

Hello,

On Thu, 28 Sep 2023, at 15:47, John Mattsson wrote:
>
> EDHOC is high level very similar to the TLS 1.3 handshake but has much 
> smaller message sizes and is therefore useful in IoT. EAP-EDHOC is just 
> EDHOC over EAP using the EAP-TLS request and response packet formats.

To help get me behind this it would be interesting to see comparisons made against existing EAP methods.

For example, how much smaller and better for your use case is EAP-EDHOC compared to:

 * plain vanilla flavoured EAP-TLS
 * why is NewSessionTicket (session resumption)
 * though a draft, make some predictions if there was a EAP-cTLS (based off draft-ietf-tls-ctls) implementation
 * what if RPK (RFC7250) was an option; draft-chen-emu-eap-tls-ibs attempted this but also lacked information on how much you gained by doing this
 * could "Trusted CA Indication" (RFC6066, section 6) help; though it probably would need adding to OpenSSL[1]

How much slimmer do you need EAP-TLS to be to make EAP-EDHOC no longer necessary? Or is the shape of it just completely inappropriate?

>From my perspective, I see work in the pipeline that could be called on to trim EAP-TLS in a manner that would only require implementers to make tweaks to their existing implementations.

If you can show that there is seemingly no way to get EAP-TLS (or anything else) to fit the bill, it would convince me that this is a good place to put my energy into.

Cheers

Alex

[1] https://github.com/openssl/openssl/issues/3029