Re: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

Eric Rescorla <ekr@rtfm.com> Mon, 22 June 2020 00:31 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27823A0855 for <lake@ietfa.amsl.com>; Sun, 21 Jun 2020 17:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.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 x4FQb6_pUNDo for <lake@ietfa.amsl.com>; Sun, 21 Jun 2020 17:31:53 -0700 (PDT)
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 6F1343A0854 for <lake@ietf.org>; Sun, 21 Jun 2020 17:31:53 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id y11so17315991ljm.9 for <lake@ietf.org>; Sun, 21 Jun 2020 17:31:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WtEkUuNtZF1UmmKNNAUGg0MaNmjQ8nsGC4+IQh3yGFM=; b=A616di4ox1+eAkUGtQBx6Wul01ggaG6N4/Oq3liS3J483tOvNNYCc8x2LYPDgHA9fd Fkb0dlenIdxm800QNdnb7502gfq63JkfYAcUajKu8PphigVrAPuZYaofG3Udeq+dzEcK 46v4BZgi/qD9LfiZwxlrZeSuYVbKYH51Uf8eiloOLsZoEvp53nN22mLJlaWcA16JfgvF fce9MKeKuI6hIt0raElqCx7bBNNMG/kgFH/UYYeEVh47NKKt7/4VG4Ski2KuFU80CNiT UcxvfA6Vz+lQuH1JLJmhRQDU0MkhPLIwb57csxOnBL+sz0gWm7vy9texbZKxno4waDiL 6wOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WtEkUuNtZF1UmmKNNAUGg0MaNmjQ8nsGC4+IQh3yGFM=; b=VbCsXKV1Q4EBdeqa/IHgoIY5po3cyrxq1/3BC2tNqhL5dj5YYDv4jyePzc0x925Zvt 2A9B5SUcgGO0fQBKHwmWqFbBlfthOpLecJPp77gCD3Jf7pDWJNqGGvPhTM3eArkvUE4K 67qOIhaJTHHUgRVJj+1Wl+/OLob3MEuOaTXG6IZBJZE5TJdgKaYitK/z98OgOuRGw2G5 Ck4xIO2DcM6xsAzT21h7L4BSa1dERWan3IMVLUbz1kf0KCF4b2sdhs6EroB8LnjBdKZ5 NiDbngMalQ5AYgW2Wxh8wb6oXnxvrzwlICrysJUzlw3YeryIt8d5qM2TUf7ymzT4d+Bd ECrw==
X-Gm-Message-State: AOAM531wGsMOR6y1jNohxLLuQzf7LUVBykHt0BXn/Uju8JsDsLD5kuDE MpWDlr8hiHx/Sfq3+4Ndw4Y8IlzdzbEA3u1PTTuT2g==
X-Google-Smtp-Source: ABdhPJyR9fe3OdEDCp8TU5rE2hqawoc4sQnubQapXnj3sDD5/XG5/fmsl46pmEjeeNOf14RgkoXdj8iM5tSMF2oGN1M=
X-Received: by 2002:a2e:81d4:: with SMTP id s20mr7186347ljg.184.1592785911462; Sun, 21 Jun 2020 17:31:51 -0700 (PDT)
MIME-Version: 1.0
References: <89EA6A63-AB99-4649-9F08-D6FBDE1DEF2F@inria.fr> <e86bb20d-8092-9b13-76b9-220de4f00e64@ri.se> <f8337bf9-40d2-557c-0e15-53571644900a@afnic.fr> <bfe96788-ec1a-2c9e-2fab-d52fb9fd8990@um.es> <640332b4-188d-4ca7-9c41-310a3d0a73ed@www.fastmail.com>
In-Reply-To: <640332b4-188d-4ca7-9c41-310a3d0a73ed@www.fastmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 21 Jun 2020 17:31:15 -0700
Message-ID: <CABcZeBPpf8nKHmch-hD5WozGnQnVpVxi8cp+HsQCA3uF01aJ-A@mail.gmail.com>
To: Christopher Wood <caw@heapingbits.net>
Cc: lake@ietf.org
Content-Type: multipart/alternative; boundary="00000000000074c4e605a8a15ec5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/ezms3TvZur1Ii8dUyKV6BTuKxPg>
Subject: Re: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jun 2020 00:31:56 -0000

I don't think it's surprising that I also don't favor adoption. In
general, I believe that there are a lot of advantages to reusing an
existing AKE, because we inherit not only the analysis of that AKE but
also all the work that goes into extending it, both in the past and in
the future.

I do think there are settings where it makes sense to standardize a
new AKE. For example, group messaging is a radically different setting
and therefore designing a new AKE (MLS) was a much better idea than
trying to repurpose one of our existing ones (TLS, IKE, or GKMP,
etc.). However, in this case we have a setting which is quite similar
to that for which TLS was designed and differs primarily in message
size. Were this setting radically simpler than the TLS setting,
then it might still make sense to design something new, but as
I read the requirements, they're actually not particularly simple
and it seems likely they will eventually expand.

This leaves us with the question of message size. However, as cTLS
appears to be able to meet the consensus message size requirements, I
do not believe it is necessary to adopt and standardize EDHOC.

-Ekr



On Sun, Jun 21, 2020 at 4:52 PM Christopher Wood <caw@heapingbits.net>
wrote:

> I do not support adoption.
>
> The charter of this WG states:
>
>    draft-selander-ace-cose-ecdhe is a candidate
>    starting point for the LAKE produced by the WG. Any work available from
>    TLS or other WGs that satisfies the determined requirements will also be
>    evaluated for suitability, but does not preclude the WG from freely
>    selecting its preferred LAKE for OSCORE.
>
> Unless I missed it, work from TLS was not seriously evaluated for
> suitability.
> In fact, it seems we jumped right over it and landed on
> draft-selander-ace-cose-ecdhe.
> The cTLS authors demonstrated that this variant of the protocol can indeed
> meet
> the requirements set out in draft-ietf-lake-reqs-04, without compromising
> any of
> the benefits that the TLS ecosystem brings to the table. (Support for
> different
> server authentication modes, for example, is something TLS is well
> equipped to support.)
>
> I understand that the TLS WG adopted cTLS and will continue its
> development there.
> However, that does not seem relevant for what this WG chooses. By analogy,
> this would
> be similar to QUIC developing its own key exchange protocol since UDP is
> just slightly
> different from TCP. Clearly, that was not the path chosen, and I think it
> would be a
> mistake to do that here without seriously considering cTLS.
>
> Best,
> Chris
>
> On Sun, Jun 21, 2020, at 1:13 PM, Jesus Sanchez-Gomez wrote:
> > Hello All,
> >
> > I support the adoption of this document.
> >
> > I've worked with the technology in research projects/papers yielding
> > good results.
> >
> > There are several use cases where this technology is a good solution for
> > different research projects at the University of Murcia and Odin
> Solutions.
> >
> > While I've practical experience with this technology working
> > specifically in LoRaWAN, its design makes it a good fit for any
> > constrained radio link/LPWAN.
> >
> > Also, it has potential to be implemented beyond LPWANs, like more
> > generic IoT scenarios with large scalability.
> >
> > Best Regards,
> >
> >
> > --
> > Jesús Sánchez Gómez
> > Contratado predoctoral // Phd Student. Fundación Séneca. Comunidad
> > Autónoma de la Región de Murcia
> > +34 868 88 96 74
> > +34 635 33 26 09
> > jesus.sanchez4@um.es
> > Department of Information and Communication Engineering
> > Faculty of Computer Science
> > University of Murcia
> > 30100 Murcia, Spain
> >
> > --
> > Lake mailing list
> > Lake@ietf.org
> > https://www.ietf.org/mailman/listinfo/lake
> >
>
> --
> Lake mailing list
> Lake@ietf.org
> https://www.ietf.org/mailman/listinfo/lake
>