IETF Logo Mail Archive

Re: [Secdispatch] EDHOC Summary

Benjamin Kaduk <kaduk@mit.edu> Fri, 19 April 2019 04:25 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A472120086 for <secdispatch@ietfa.amsl.com>; Thu, 18 Apr 2019 21:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Ucz39eynVWa4 for <secdispatch@ietfa.amsl.com>; Thu, 18 Apr 2019 21:25:34 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A638512000E for <secdispatch@ietf.org>; Thu, 18 Apr 2019 21:25:34 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3J4PNi0032035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Apr 2019 00:25:25 -0400
Date: Thu, 18 Apr 2019 23:25:23 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: "Owen Friel (ofriel)" <ofriel@cisco.com>, Göran Selander <goran.selander@ericsson.com>, Richard Barnes <rlb@ipv.sx>, Michael Richardson <mcr+ietf@sandelman.ca>, Carsten Bormann <cabo@tzi.org>, "secdispatch@ietf.org" <secdispatch@ietf.org>, Martin Thomson <mt@lowentropy.net>
Message-ID: <20190419042522.GF95327@kduck.mit.edu>
References: <CY4PR11MB1541D6FD27E0FBD478FCF362DB2B0@CY4PR11MB1541.namprd11.prod.outlook.com> <AM6PR08MB36866DB97940341DB43D8331FA240@AM6PR08MB3686.eurprd08.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <AM6PR08MB36866DB97940341DB43D8331FA240@AM6PR08MB3686.eurprd08.prod.outlook.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/E7ZfvVUszHZ7q3D5ZtDW6z4XsqI>
Subject: Re: [Secdispatch] EDHOC Summary
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Apr 2019 04:25:36 -0000

Hi Hannes,

On Tue, Apr 16, 2019 at 07:26:02AM +0000, Hannes Tschofenig wrote:
> >     Richard Barnes <rlb@ipv.sx<mailto:rlb@ipv.sx>> wrote:
> >         > I'd like to push back on this point. It may be that EDHOC has been around for
> >         > a while and been well-socialized with the IoT crowd, but it is clearly
> >         > deficient in several other types of maturity, e.g., robustness of formal
> >         > analyses and state of implementations (AFAICT).
> 
> I would like to point out that initially the work on EDHOC was intentionally not positioned as a TLS replacement (or even competitor).
> For years I was told that it is supposed to be used in addition to and on top of TLS.
> 
> Fast forward a few years the story is very different now.

I'm not sure that this line of discussion is going to be very productive.
Plans can change over time, and of course a technology that is inspired for
one use case can take off and become a key part of designs all over the
place (consider, perhaps, the wild success of the DNS, or as a less extreme
example the wide variety of things people want to do with BRSKI).

The specific technical issue in front of us seems to be a claim that there
is a scenario with wide deployment applicability where the (mostly size)
message constraints are such that stock TLS is not applicable and an
alternative AKE is needed.  This is not surprising given that stock TLS has
not really been designed to skimp on the byte count of message encoding,
though of course we can revisit that aspect of TLS in some ways.

I would welcome technical reasoning that, e.g., the indicated scenario(s)
do not actually have wide deployment applicability, or that stock TLS is in
fact usable in these scenarios, but the history of EDHOC's origins does not
really seem relevant to the technical issues.

Thanks,

Ben

v2.23.0 | Report a Bug | By Email