IETF Logo Mail Archive

Re: [Emu] Adoption call for EAP-DPP

Eliot Lear <lear@lear.ch> Thu, 08 September 2022 07:42 UTC

Return-Path: <lear@lear.ch>
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 DBA37C14F75F for <emu@ietfa.amsl.com>; Thu, 8 Sep 2022 00:42:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=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 (1024-bit key) header.d=lear.ch
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 uDNmTO_AfSXr for <emu@ietfa.amsl.com>; Thu, 8 Sep 2022 00:42:11 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 2F16EC14F725 for <emu@ietf.org>; Thu, 8 Sep 2022 00:42:09 -0700 (PDT)
Received: from [IPV6:2001:420:c0c0:1001::3ee] ([IPv6:2001:420:c0c0:1001:0:0:0:3ee]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 2887g0a6700759 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 8 Sep 2022 09:42:01 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1662622921; bh=n15xagowqhInO7P1SfEX6Aei/r78GiydD/iudymwtZs=; h=Date:Subject:To:References:From:In-Reply-To:From; b=nTOmmTOzCANXCFOJiuv2ZbWvA1Q0UlHoRWMQxDmpnkGsqKp/t7xyoFLe7uagDwz3b +lFdtPm3aRyX4qluT7UO4eMWLGK4VmdQLJAi5jb58UV1EpMHwjvC4fwbENcggL8rz2 foTy33KDdfwoGaWYuIU08FzhnAakuIjmdmJzqiOw=
Message-ID: <58c6f545-b17d-087c-4d9a-c3cb9a1e2a0b@lear.ch>
Date: Thu, 08 Sep 2022 09:41:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.0
Content-Language: en-US
To: Peter Yee <peter@akayla.com>, emu@ietf.org
References: <006a01d8c33f$89efa6d0$9dcef470$@akayla.com>
From: Eliot Lear <lear@lear.ch>
In-Reply-To: <006a01d8c33f$89efa6d0$9dcef470$@akayla.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------O6Tu0ROoI0xZnMlGXeZq5cZT"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/jXGTGnPKyLEzIK9lf2Fvcg9d5oE>
Subject: Re: [Emu] Adoption call for EAP-DPP
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: Thu, 08 Sep 2022 07:42:16 -0000

Peter,

Let me clarify why I think it's important to adopt this work. The Wifi 
Alliance has already standardized the public/private key pair as well as 
other attributes that can be used to securely onboard a device.  They 
have also standardized the QR code used to represent this information.  
DPP has reasonably good support in the widely distributed wpa_supplicant 
code, and that gets us a long way... for wireless.

We need that sort of capability for wired devices as well. Owen's and 
Dan's work provides that parity using the *identical* bootstrapping 
information, QR code representation, and algorithm. *AND* there's 
already code.  And it's a pretty elegant solution.

So.. I'd ask that people take a look.

Eliot

On 08.09.22 06:57, Peter Yee wrote:
> In retrospect, sending the call for adoption at the height of August
> vacation season may not have guaranteed the most responses. To be honest,
> the level of responses to this call has been a little light, so Joe and I
> have decided to extend the call for adoption for one week from today.
>
> We would really like to hear from anyone else who is interested in reviewing
> and/or contributing to this specification or anyone who feels that it should
> not be adopted. Please speak up by the 14th either way. This specification
> would seemingly fit within the WG's existing charter, so let your voice be
> heard!
>
> Thanks,
>
> Peter and Joe
>
> -----Original Message-----
> From: Peter Yee<peter@akayla.com>  
> Sent: Tuesday, August 16, 2022 1:12 PM
> To: 'emu@ietf.org'<emu@ietf.org>
> Subject: Adoption call for EAP-DPP
>
> This is an adoption call for EAP-DPP (draft-friel-tls-eap-dpp-05)[1]. This
> document aligns with the charter item to "Define mechanisms by which EAP
> methods can support creation of long-term credentials for the peer based on
> initial limited-use credentials." The latest revision incorporates feedback
> from both the TLS and EMU working groups. Please review and respond to the
> list if you think this document is or is not an appropriate working group
> item for EMU by September 1, 2022.
>
> Thanks,
>
> Peter and Joe
>
> [1]https://datatracker.ietf.org/doc/draft-friel-tls-eap-dpp/
>
>
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>

v2.23.0 | Report a Bug | By Email