From nobody Thu Feb 21 06:05:37 2019 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CF3129284 for ; Thu, 21 Feb 2019 06:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 Q66R4sObo_uA for ; Thu, 21 Feb 2019 06:05:32 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id A5E3B1279E6 for ; Thu, 21 Feb 2019 06:05:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1550757927; d=isode.com; s=june2016; i=@isode.com; bh=v026KldSIn5JMDBQ8fgdk9QpYhK/BjdF8NIuN45vRgc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=FR7B5j0NCM6YEOPz0A9CGvryTpacUyig2XMabH8/RuKlrZ1FKn+2i1OFkw0YoQ0vFEqO4g ImfkMsbfBzUUD9XDlp1JW7cAplT27IDFWxzVNBovfFwnUhHrAQxmYEQNdnalq1mXhOmuOu iNg66d/VOaMqGz2VTaDUmO9WqoBf7xY=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 21 Feb 2019 14:05:27 +0000 To: "crypto-panel@irtf.org" Cc: "'Roman D. Danyliw'" From: Alexey Melnikov Message-ID: <5e587cf8-2275-b682-e390-e83529a8d0d8@isode.com> Date: Thu, 21 Feb 2019 14:05:03 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------878EE3B79122B8A274896112" Content-Language: en-GB Archived-At: Subject: [Crypto-panel] Request to review: draft-selander-ace-cose-ecdhe-11 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 14:05:37 -0000 This is a multi-part message in MIME format. --------------878EE3B79122B8A274896112 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear Crypto Panel members, CFRG chairs received a request to review this document (maybe even 2 reviews), ideally by March 4. (If you miss the deadline, a review that is completed later is still useful.) Any takers? In particular, the review should concentrate on the following aspects of the proposal: EDHOC (https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe-11) is being proposed as a new AKE to meet the need of constrained/IoT environments (such as those considered by the ACE WG). Formal analysis on -08 was conducted by [1] [2]. A review by the Crypto Review Panel would be helpful to evaluate the security properties (mutual authentication, PFS, and identity protection) claimed by the draft: ** Top-line: does EDHOC provide the security properties it asserts? How do we reason about/approach answering that question? ** Is this draft complete -- what would you like to see that isn't written? ** What areas of the draft or features of the protocol require further analysis or polish? Are the prerequisite/assumptions clear enough? ** Are the choice of ciphersuites acceptable? ** Does the formal analysis in [1] appear credible? ** Does -11 appear to have addressed the concerned outlined by [1] in -08? (The authors of [1] are working on an update of the analysis on -11) A related key question being discussed is "ignoring whether the security properties of EDHOC are valid, can the 'lightweight property of EDHOC' be realized with another protocol" [1] https://link.springer.com/content/pdf/10.1007%2F978-3-030-04762-7_2.pdf [2] https://github.com/theisgroenbech/edhoc-proverif Thank you, Alexey --------------878EE3B79122B8A274896112 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Dear Crypto Panel members,

CFRG chairs received a request to review this document (maybe even 2 reviews), ideally by March 4. (If you miss the deadline, a review that is completed later is still useful.) Any takers?

In particular, the review should concentrate on the following aspects of the proposal:

EDHOC (https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe-11) is being proposed as a new AKE to meet the need of constrained/IoT environments (such as those considered by the ACE WG). Formal analysis on -08 was conducted by [1] [2]. A review by the Crypto Review Panel would be helpful to evaluate the security properties (mutual authentication, PFS, and identity protection) claimed by the draft: 

** Top-line: does EDHOC provide the security properties it asserts?  How do we reason about/approach answering  that question?
** Is this draft complete -- what would you like to see that isn't written?
** What areas of the draft or features of the protocol require further analysis or polish?  Are the prerequisite/assumptions clear enough?
** Are the choice of ciphersuites acceptable? 
** Does the formal analysis in [1] appear credible?
** Does -11 appear to have addressed the concerned outlined by [1] in -08? (The authors of [1] are working on an update of the analysis on -11)

A related key question being discussed is "ignoring whether the security properties of EDHOC are valid, can the 'lightweight property of EDHOC' be realized with another protocol"

[1] https://link.springer.com/content/pdf/10.1007%2F978-3-030-04762-7_2.pdf
[2] https://github.com/theisgroenbech/edhoc-proverif

Thank you,
Alexey
--------------878EE3B79122B8A274896112-- From nobody Thu Feb 21 06:54:01 2019 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F131286E7 for ; Thu, 21 Feb 2019 06:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 8AKodenSXahe for ; Thu, 21 Feb 2019 06:53:57 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E778B12D7F8 for ; Thu, 21 Feb 2019 06:53:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A7F25300AA4 for ; Thu, 21 Feb 2019 09:35:38 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id m-4SrzBydCAJ for ; Thu, 21 Feb 2019 09:35:36 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 51E4530024F; Thu, 21 Feb 2019 09:35:36 -0500 (EST) From: Russ Housley Message-Id: <391B20B9-283A-4B36-805A-251D190B2E30@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0C9F4CA3-7F43-4F75-B29B-380F1B7DAE3F" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 21 Feb 2019 09:53:52 -0500 In-Reply-To: <5e587cf8-2275-b682-e390-e83529a8d0d8@isode.com> Cc: "crypto-panel@irtf.org" , "Roman D. Danyliw" To: Alexey Melnikov References: <5e587cf8-2275-b682-e390-e83529a8d0d8@isode.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Crypto-panel] Request to review: draft-selander-ace-cose-ecdhe-11 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 14:54:00 -0000 --Apple-Mail=_0C9F4CA3-7F43-4F75-B29B-380F1B7DAE3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes, I can take a look at it next week. Russ > On Feb 21, 2019, at 9:05 AM, Alexey Melnikov = wrote: >=20 > Dear Crypto Panel members, >=20 > CFRG chairs received a request to review this document (maybe even 2 = reviews), ideally by March 4. (If you miss the deadline, a review that = is completed later is still useful.) Any takers? >=20 > In particular, the review should concentrate on the following aspects = of the proposal: >=20 > EDHOC = (https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe-11 = ) is = being proposed as a new AKE to meet the need of constrained/IoT = environments (such as those considered by the ACE WG). Formal analysis = on -08 was conducted by [1] [2]. A review by the Crypto Review Panel = would be helpful to evaluate the security properties (mutual = authentication, PFS, and identity protection) claimed by the draft: >=20 > ** Top-line: does EDHOC provide the security properties it asserts? = How do we reason about/approach answering that question? > ** Is this draft complete -- what would you like to see that isn't = written? > ** What areas of the draft or features of the protocol require further = analysis or polish? Are the prerequisite/assumptions clear enough? > ** Are the choice of ciphersuites acceptable?=20 > ** Does the formal analysis in [1] appear credible? > ** Does -11 appear to have addressed the concerned outlined by [1] in = -08? (The authors of [1] are working on an update of the analysis on = -11) >=20 > A related key question being discussed is "ignoring whether the = security properties of EDHOC are valid, can the 'lightweight property of = EDHOC' be realized with another protocol" >=20 > [1] = https://link.springer.com/content/pdf/10.1007%2F978-3-030-04762-7_2.pdf = > [2] https://github.com/theisgroenbech/edhoc-proverif = >=20 > Thank you, > Alexey > _______________________________________________ > Crypto-panel mailing list > Crypto-panel@irtf.org > https://www.irtf.org/mailman/listinfo/crypto-panel --Apple-Mail=_0C9F4CA3-7F43-4F75-B29B-380F1B7DAE3F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Yes, I can take a look at it next week.

Russ


On Feb 21, 2019, at 9:05 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:

Dear Crypto Panel members,

CFRG chairs received a request to review this document (maybe even 2 reviews), ideally by March 4. (If you miss the deadline, a review that is completed later is still useful.) Any takers?

In particular, the review should concentrate on the following aspects of the proposal:

EDHOC (https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe-11) is being proposed as a new AKE to meet the need of constrained/IoT environments (such as those considered by the ACE WG). Formal analysis on -08 was conducted by [1] [2]. A review by the Crypto Review Panel would be helpful to evaluate the security properties (mutual authentication, PFS, and identity protection) claimed by the draft: 

** Top-line: does EDHOC provide the security properties it asserts?  How do we reason about/approach answering  that question?
** Is this draft complete -- what would you like to see that isn't written?
** What areas of the draft or features of the protocol require further analysis or polish?  Are the prerequisite/assumptions clear enough?
** Are the choice of ciphersuites acceptable? 
** Does the formal analysis in [1] appear credible?
** Does -11 appear to have addressed the concerned outlined by [1] in -08? (The authors of [1] are working on an update of the analysis on -11)

A related key question being discussed is "ignoring whether the security properties of EDHOC are valid, can the 'lightweight property of EDHOC' be realized with another protocol"

[1] https://link.springer.com/content/pdf/10.1007%2F978-3-030-04762-7_2.pdf
[2] https://github.com/theisgroenbech/edhoc-proverif

Thank you,
Alexey
_______________________________________________
Crypto-panel mailing list
Crypto-panel@irtf.org
https://www.irtf.org/mailman/listinfo/crypto-panel

--Apple-Mail=_0C9F4CA3-7F43-4F75-B29B-380F1B7DAE3F-- From nobody Thu Feb 21 23:58:34 2019 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FA5128D52 for ; Thu, 21 Feb 2019 23:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gIlFXOaZOrIF for ; Thu, 21 Feb 2019 23:58:29 -0800 (PST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 BB0CD126D00 for ; Thu, 21 Feb 2019 23:58:29 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id y140so627230qkb.9 for ; Thu, 21 Feb 2019 23:58:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vnsPK7AscjsdHOhL58k9myR9/qOk+0Tgvc8zmJqecPc=; b=b/+m96BxikAYsr1lOO9ZLdqmiBbpnDauOg2tZYQCY6SzqSG8efHKBoq3XGRb8z1opn psvmUGF2wKURyI5YIadORCSLDv4X8Vnm/I23igqYH07ipIRuMffHjfm8DLRpGIQ9m1Bo pA1ZnW2EG3uN/6xi8Uhkp/O4cPjNIZSA/hmpU7CJ7Q2ZCxhYWf5TJNumaUlVwh/74Cy3 bFqlDgBMDzB3MPJ9vqV0HGtlIJUaNmPw/PQkK7aeb5jlDwl9Yydr82hfGWnGFmF835iK IvFcyekIXX/SwKXIoKQKv+bwQnWi0xZptGzQL3mCIV4EYOrBHgp9nKsZ0bnG4h2BrXnK /GLA== 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=vnsPK7AscjsdHOhL58k9myR9/qOk+0Tgvc8zmJqecPc=; b=e+p8jGfQsrsA+aI69yM4fQWJk3lV7e+xxsGG5MJTY2XJbFFETOsaoo3ghgnUm8v30L ctdDBqanF0RWQ1CFrwgfBPTRplWFzSsir8SAD044LYISC2etJC0x1mk+Qu/W5NiRIqbv hXb/Np8rcmnJ7z6cugeFRLhX7MxiU7eOmLwOX1v7VpdNrvMJCjLahHCYDMXA3gkq7LiT oyvfblJ4Vil2oKve/v/xKnxbeB0J90VUjTbngXXe5I4r8VAbj6vUrj3b5dvIECr0mWsz M4PU4P9Yvrpl3S+o3kC8LBRfBNYk5kK5SGG/uZvR7JkL/rnyl9NMkAKbLq8STfFHoNmc iHXQ== X-Gm-Message-State: AHQUAuZYnAxkz4bXempndr9bRRRdLyYrhZcSrzthj840VILty5XBp3fl /qCpANXMXCsUuSiDuqgU1FpeWibPeqJCFzYFM3/J9Q== X-Google-Smtp-Source: AHgI3IYFr8R/o9vJqL4Bbh2Fy3mmdNBbNwdq/IoM5r4O9duZOCdrsBP37XKQWIdM9/7rSTOAtGn1ikFBThRV/uzzRKA= X-Received: by 2002:a37:d612:: with SMTP id t18mr1983913qki.215.1550822308542; Thu, 21 Feb 2019 23:58:28 -0800 (PST) MIME-Version: 1.0 References: <5e587cf8-2275-b682-e390-e83529a8d0d8@isode.com> <391B20B9-283A-4B36-805A-251D190B2E30@vigilsec.com> In-Reply-To: <391B20B9-283A-4B36-805A-251D190B2E30@vigilsec.com> From: "Stanislav V. Smyshlyaev" Date: Fri, 22 Feb 2019 12:58:16 +0500 Message-ID: To: Russ Housley Cc: Alexey Melnikov , "Roman D. Danyliw" , "crypto-panel@irtf.org" Content-Type: multipart/alternative; boundary="000000000000cf7ea3058276f45c" Archived-At: Subject: Re: [Crypto-panel] Request to review: draft-selander-ace-cose-ecdhe-11 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 07:58:32 -0000 --000000000000cf7ea3058276f45c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear colleagues! I=E2=80=99ll do it too. The deadline (March, 4th) is rather tight, but I=E2=80=99ll try my best to = provide my review until that date. Best regards, Stanislav =D1=87=D1=82, 21 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0=B2 19:54, Russ = Housley : > Yes, I can take a look at it next week. > > Russ > > > On Feb 21, 2019, at 9:05 AM, Alexey Melnikov > wrote: > > Dear Crypto Panel members, > > CFRG chairs received a request to review this document (maybe even 2 > reviews), ideally by March 4. (If you miss the deadline, a review that is > completed later is still useful.) Any takers? > > In particular, the review should concentrate on the following aspects of > the proposal: > > EDHOC (https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe-11) > is being proposed as a new AKE to meet the need of constrained/IoT > environments (such as those considered by the ACE WG). Formal analysis on > -08 was conducted by [1] [2]. A review by the Crypto Review Panel would b= e > helpful to evaluate the security properties (mutual authentication, PFS, > and identity protection) claimed by the draft: > > ** Top-line: does EDHOC provide the security properties it asserts? How = do we reason about/approach answering that question? > ** Is this draft complete -- what would you like to see that isn't writte= n? > ** What areas of the draft or features of the protocol require further an= alysis or polish? Are the prerequisite/assumptions clear enough? > ** Are the choice of ciphersuites acceptable? > ** Does the formal analysis in [1] appear credible? > ** Does -11 appear to have addressed the concerned outlined by [1] in -08= ? (The authors of [1] are working on an update of the analysis on -11) > > A related key question being discussed is "ignoring whether the security = properties of EDHOC are valid, can the 'lightweight property of EDHOC' be r= ealized with another protocol" > > [1] https://link.springer.com/content/pdf/10.1007%2F978-3-030-04762-7_2.p= df > [2] https://github.com/theisgroenbech/edhoc-proverif > > Thank you, > Alexey > > _______________________________________________ > Crypto-panel mailing list > Crypto-panel@irtf.org > https://www.irtf.org/mailman/listinfo/crypto-panel > > > _______________________________________________ > Crypto-panel mailing list > Crypto-panel@irtf.org > https://www.irtf.org/mailman/listinfo/crypto-panel > --000000000000cf7ea3058276f45c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear colleagues!

I=E2=80=99ll do it too.=C2=A0
=
The deadline (March, 4th) is rather tight, but = I=E2=80=99ll try my best to provide my review until that date.=C2=A0
<= div dir=3D"auto">
Best regards,
Stanislav


=D1=87=D1=82, 21 =D1=84=D0= =B5=D0=B2=D1=80. 2019 =D0=B3. =D0=B2 19:54, Russ Housley <housley@vigilsec.com>:
Yes, I can take a look at it next week.

Russ


On Feb 21, 2019, at 9:05 = AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:

=20 =20 =20

Dear Crypto Panel members,

CFRG chairs received a request to review this document (maybe even 2 reviews), ideally by March 4. (If you miss the deadline, a review that is completed later is still useful.) Any takers?

In= particular, the review should concentrate on the following aspects of the proposal:

EDHOC (https://datatracker.ietf.org/doc/draft-selander-ace-cose-e= cdhe-11) is being proposed as a new AKE to meet the need of constrained/IoT environments (such as those considered by the ACE WG). Formal analysis on -08 was conducted by [1] [2]. A review by the Crypto Review Panel would be helpful to evaluate the security properties (mutual authentication, PFS, and identity protection) claimed by the draft: 

*=
* Top-line: does EDHOC provide the security properties it asserts?  How do =
we reason about/approach answering  that question?
** Is this draft complete -- what would you like to see that isn't writ=
ten?
** What areas of the draft or features of the protocol require further anal=
ysis or polish?  Are the prerequisite/assumptions clear enough?
** Are the choice of ciphersuites acceptable?=20
** Does the formal analysis in [1] appear credible?
** Does -11 appear to have addressed the concerned outlined by [1] in -08? =
(The authors of [1] are working on an update of the analysis on -11)

A related key question being discussed is "ignoring whether the securi=
ty properties of EDHOC are valid, can the 'lightweight property of EDHO=
C' be realized with another protocol"

[1] https://link.springer.com/content/pdf/10.1007%2F978-3-030-04762-7_=
2.pdf
[2] https://github=
.com/theisgroenbech/edhoc-proverif

Thank you,
Alexey
_______________________________________________
Crypto-panel mailing lis= t
Crypto-pane= l@irtf.org
https://www.irtf.org/mailman/listinfo/crypto-panel<= /a>

___________________________= ____________________
Crypto-panel mailing list
Crypto-panel@irt= f.org
https://www.irtf.org/mailman/listinfo/crypto-panel=
--000000000000cf7ea3058276f45c--