From nobody Wed Mar 18 07:36:25 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF273A16BA for ; Wed, 18 Mar 2020 07:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 kYK7VSsuH32I for ; Wed, 18 Mar 2020 07:36:21 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 C793A3A16B9 for ; Wed, 18 Mar 2020 07:36:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 8E89E621A0 for ; Wed, 18 Mar 2020 10:36:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nbZcNAK43c-n for ; Wed, 18 Mar 2020 10:36:17 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id CE7976212E for ; Wed, 18 Mar 2020 10:36:14 -0400 (EDT) To: saag@ietf.org From: Robert Moskowitz Message-ID: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> Date: Wed, 18 Mar 2020 10:36:10 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [saag] Perfect Forward Secrecy vs Forward Secrecy X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 14:36:24 -0000 I have been asked to change all uses of the term: Perfect Forward Secrecy to Forward Secrecy As perfection is hard to attain. Now I am all for that, as in my  Orthodox Jewish background, Perfection is truly limited.  But I am quite use to the hijacking of words like awesome. But the term is pretty well baked into IETF standards. What is the 'feel' about this. Should I start a movement of using "Forward Secrecy" and the Security Directorate will back this position, getting all current drafts to change as well? Thank you for your opinions. From nobody Wed Mar 18 07:48:37 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8313A16EB for ; Wed, 18 Mar 2020 07:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=akamai.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 wCFwmnHOBFvM for ; Wed, 18 Mar 2020 07:48:34 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 823D63A16EA for ; Wed, 18 Mar 2020 07:48:29 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 02IEeK8x020220; Wed, 18 Mar 2020 14:48:25 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=FWUlg2aKyMkBGFSILFWr9goGCjMcuoTUqckYZlBKJ5s=; b=aO00622zemLgKX2tCt4TZFfsXPE7YAE8l3LoUtCBe+zr6wCyjdjV+bw/4AD7o1uhfFyQ 0A78n1Wgef193mnSBJ2KQ6AJTehOn9JyvPLqcUzD3RHrC75D8zQw1DrpLrkc0xT8S/qL 28RNoe295THLxn9kx+Ow2HfDve9Var3YsH4hWnR9bbOKtaF9CG8t8rDDxXXPsX4A+KdX qwR5Lp8xnR5MAS2pR46vr+H9NvSla9YJ7buZS9KNy5eGwq8eVaJounRSeFPdWeKGg7dF eM3x/8lZXY1cVSi/cSziAuHYfaiJuYSG8Zil+0+vEGShY+gR+5iV7MWeebgBLTkQQDZX zQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2yrn7hub84-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Mar 2020 14:48:25 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 02IEl9bB006356; Wed, 18 Mar 2020 10:48:24 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2yrtkvkht9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Mar 2020 10:48:24 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb6.msg.corp.akamai.com (172.27.123.54) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 18 Mar 2020 10:48:23 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 18 Mar 2020 10:48:23 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.006; Wed, 18 Mar 2020 10:48:23 -0400 From: "Salz, Rich" To: Robert Moskowitz , "saag@ietf.org" Thread-Topic: [saag] Perfect Forward Secrecy vs Forward Secrecy Thread-Index: AQHV/TLqTHSW60AdJUaA8tliUwKoBqhObiQA Date: Wed, 18 Mar 2020 14:48:22 +0000 Message-ID: References: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> In-Reply-To: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.118.63] Content-Type: text/plain; charset="utf-8" Content-ID: <311F5A48AA6E074094F69BD7F69E002B@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.645 definitions=2020-03-18_06:2020-03-18, 2020-03-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=776 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2003180071 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.645 definitions=2020-03-18_06:2020-03-18, 2020-03-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 impostorscore=0 suspectscore=0 lowpriorityscore=0 mlxscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=749 spamscore=0 clxscore=1011 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003180071 Archived-At: Subject: Re: [saag] Perfect Forward Secrecy vs Forward Secrecy X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 14:48:36 -0000 V2FzIHRoZSBwZXJzb24gd2hvIGFza2VkIHlvdSB0byBtYWtlIHRoZSBjaGFuZ2UgYSBzZWN1cml0 eSBwZXJzb24/DQpDYW4geW91IGFzayB0aGVtIGZvciBhIHJhdGlvbmFsZT8NCg0KSSBhZ3JlZSBw ZXJmZWN0IGZvcndhcmQgc2VjcmVjeSBpcyB0aGUgdGVybSBvZiBhcnQgYW5kIHdlIHNob3VsZG4n dCBjcmVhdGUgYSBuZXcgb25lLiANCg0K From nobody Wed Mar 18 07:53:39 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1FD3A16DD for ; Wed, 18 Mar 2020 07:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 38Dys5QC90P2 for ; Wed, 18 Mar 2020 07:53:36 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 BD6DF3A16AD for ; Wed, 18 Mar 2020 07:53:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 5B9A4621A0; Wed, 18 Mar 2020 10:53:35 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Rb5cWzXN7H-R; Wed, 18 Mar 2020 10:53:33 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id CF78B6212E; Wed, 18 Mar 2020 10:53:32 -0400 (EDT) To: "Salz, Rich" , "saag@ietf.org" References: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> From: Robert Moskowitz Message-ID: <89121466-d091-5f22-a053-a2a618946908@htt-consult.com> Date: Wed, 18 Mar 2020 10:53:32 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [saag] Perfect Forward Secrecy vs Forward Secrecy X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 14:53:38 -0000 On 3/18/20 10:48 AM, Salz, Rich wrote: > Was the person who asked you to make the change a security person? A Sec AD. > Can you ask them for a rationale? His preference as, "perfection is hard to attain." > I agree perfect forward secrecy is the term of art and we shouldn't create a new one. > Why I feel this ship has sailed. Lots in English usage I cringe at and just have to accept. "Ecologize"  really set me off when I first heard it.  My area of study for my B.S. in Botany in '72 was Botanical Successional Ecology. From nobody Wed Mar 18 07:59:37 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FD73A1700 for ; Wed, 18 Mar 2020 07:59:36 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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=heapingbits.net header.b=R5GR5NQ8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Hy1dRWjF 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 3j8U4FZbg8VW for ; Wed, 18 Mar 2020 07:59:35 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1E53A16FD for ; Wed, 18 Mar 2020 07:59:35 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 425F35C02A7 for ; Wed, 18 Mar 2020 10:59:34 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Wed, 18 Mar 2020 10:59:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=lmN2DChNWAkv+kYBBr5yVcHJpLrNPzK AiMn0UoakCn8=; b=R5GR5NQ8kw0B+eBJBTHTxc5bFbORilruXJA4CWBjdrHohix BeGeh1BB8rygC4ZUZq8CAzh106bMFWrmX1fQXVxjFRR+ld7BMg/On5Lrygoq2cWQ earXJkYIj0DLPujBZW6fO6Gk/qZeL5um1FvbikMUzDpfM+uaKC697qtQ2oTQNV17 dD8P5/tz2ClVRtslFlXZdXMqhx8De2FMRoZH1RawXogOZEInN3ZCswaq3xTRSiW1 yzqmOOQoDZSHqfcv0yOUAq6r/VM8uKMhteUXuleWP5n0sEpEIPxCu5ijkIfLyI/N lBBrlzNrl+Yre2s4Rc7YYFyqNv/m3O2Fu/Bs17A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=lmN2DC hNWAkv+kYBBr5yVcHJpLrNPzKAiMn0UoakCn8=; b=Hy1dRWjFgU7X8bknG+RwKf 20SWifd2Y7Stb699eW0jCdMY6vcK3Mj4+a662mlYLlSjTbRb1Oj/JVj1cWVwMu9u kaIMVaWQfSlTbwkKI32pmtWVpmWOgIN+LDu4fXtilUwwNCb3NMr3puxRmO97srSV 1xsqhc/vNaLYXPr0um7vTfiVymHBhKQ04H7tq6N7FdOnGeujfYmOdAtPqeNZkZbt OqVwkQQIYMjVEbNCOzwB4RUoOp2o+OBXVUqLj3B/ejm3Sc5f69EWDlNA4YVwMY0G oLqoEWg1XoS+2qAPkmq556jIrqAmQLlFm4PoM6G8eac2YwXTRq728bgjrFCmQ6zA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudefjedgieelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E59F63C00A1; Wed, 18 Mar 2020 10:59:33 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-991-g5a577d3-fmstable-20200305v3 Mime-Version: 1.0 Message-Id: <6b73afd0-6eda-4533-a499-166934702f6e@www.fastmail.com> In-Reply-To: References: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> Date: Wed, 18 Mar 2020 07:59:13 -0700 From: "Christopher Wood" To: saag@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [saag] Perfect Forward Secrecy vs Forward Secrecy X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 14:59:36 -0000 On Wed, Mar 18, 2020, at 7:48 AM, Salz, Rich wrote: > Was the person who asked you to make the change a security person? > Can you ask them for a rationale? > > I agree perfect forward secrecy is the term of art and we shouldn't > create a new one. FWIW, +1. Best, Chris From nobody Wed Mar 18 08:00:21 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BACF3A1726 for ; Wed, 18 Mar 2020 08:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=akamai.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 BZlUVj3rvU2M for ; Wed, 18 Mar 2020 08:00:10 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 9CD813A1729 for ; Wed, 18 Mar 2020 08:00:10 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 02IEvkdt031039; Wed, 18 Mar 2020 15:00:07 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=+IejO/1W5ardssHT4NfSpjsEU3RWfN68ExeZqI9Byhs=; b=M0GbhY0WKno5ZXOmVy2yWthUxLDf7qjF79eiFnD506L4OjUdbiZaXXKjpd9PF8EF6lNi NBW69p3guMXwXAT5uUdy2YhcpL6clGQSGlh1793wErB+KvbTu7wzx357x8+JP9HQ2npd IcKwActkxLYCCLmZ0B7iFHoNioPXGwb1cxZn4cMaoYPOdYiL+zVkOLx1z8xkCUXcuP/p f1TZ6knmxOrgkdySpGWdQBPq7j3wwZMwQjWhI3+MZ8pGy9kKEoaJ/hza8/bOnLbyrPuq s5izkpdbuDpacLUlP0IGsVlrHC1zofJpTaBkaxbVrAC67h4gHpo4DffRBQCadm8IkFh6 XQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2yrva68ny1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Mar 2020 15:00:07 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 02IEl7Dh018178; Wed, 18 Mar 2020 11:00:06 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2yrtkw3k9f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Mar 2020 11:00:06 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 18 Mar 2020 11:00:05 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.006; Wed, 18 Mar 2020 11:00:05 -0400 From: "Salz, Rich" To: Robert Moskowitz , "saag@ietf.org" Thread-Topic: [saag] Perfect Forward Secrecy vs Forward Secrecy Thread-Index: AQHV/TLqTHSW60AdJUaA8tliUwKoBqhObiQAgABEgAD//77FAA== Date: Wed, 18 Mar 2020 15:00:04 +0000 Message-ID: References: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> <89121466-d091-5f22-a053-a2a618946908@htt-consult.com> In-Reply-To: <89121466-d091-5f22-a053-a2a618946908@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.118.63] Content-Type: text/plain; charset="utf-8" Content-ID: <9318BEA375658D43AE153D151E6BAB85@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.645 definitions=2020-03-18_06:2020-03-18, 2020-03-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=665 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2003180071 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.645 definitions=2020-03-18_06:2020-03-18, 2020-03-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 bulkscore=0 mlxlogscore=645 lowpriorityscore=0 malwarescore=0 impostorscore=0 mlxscore=0 phishscore=0 priorityscore=1501 clxscore=1015 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003180072 Archived-At: Subject: Re: [saag] Perfect Forward Secrecy vs Forward Secrecy X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 15:00:13 -0000 PiAgICA+IFdhcyB0aGUgcGVyc29uIHdobyBhc2tlZCB5b3UgdG8gbWFrZSB0aGUgY2hhbmdlIGEg c2VjdXJpdHkgcGVyc29uPw0KICAgIA0KPiAgICBBIFNlYyBBRC4NCg0KVGhhdCdzIGRpc2FwcG9p bnRpbmcuDQoNCj4gICAgV2h5IEkgZmVlbCB0aGlzIHNoaXAgaGFzIHNhaWxlZC4NCiAgDQpBZ3Jl ZWQuDQoNCg0K From nobody Wed Mar 18 08:58:58 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6CF3A0410 for ; Wed, 18 Mar 2020 08:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 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_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, 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=cryptonector.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 JtZ1mq_mQHjR for ; Wed, 18 Mar 2020 08:58:54 -0700 (PDT) Received: from eastern.birch.relay.mailchannels.net (eastern.birch.relay.mailchannels.net [23.83.209.55]) (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 34EAF3A040F for ; Wed, 18 Mar 2020 08:58:53 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 3A87920526; Wed, 18 Mar 2020 15:58:53 +0000 (UTC) Received: from pdx1-sub0-mail-a58.g.dreamhost.com (100-96-54-11.trex.outbound.svc.cluster.local [100.96.54.11]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id B5A4020420; Wed, 18 Mar 2020 15:58:52 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a58.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Wed, 18 Mar 2020 15:58:53 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Interest-Stop: 73b510e5162be62a_1584547132998_2001366016 X-MC-Loop-Signature: 1584547132998:1489279316 X-MC-Ingress-Time: 1584547132997 Received: from pdx1-sub0-mail-a58.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a58.g.dreamhost.com (Postfix) with ESMTP id C54747F18E; Wed, 18 Mar 2020 08:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=ebnJ4tS5E6bB3P UTb2/fnjo3diQ=; b=FsA749k+j81AXW/8hbcUjgIDEeOyBFhCMNMm+cKQCJ2WPU KI/naJTp+kKemRlKW1+ZAtW2O8LBUbGBeLBcb47sFImY/+F0wBf8rdYD5JBYl2p0 0MsuumjINCMHzqNNEChLxR0K2N45xjpysr0VT9kr+c2m3q/7KOvWGaJMswOvs= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a58.g.dreamhost.com (Postfix) with ESMTPSA id 030617F19C; Wed, 18 Mar 2020 08:58:47 -0700 (PDT) Date: Wed, 18 Mar 2020 10:58:45 -0500 X-DH-BACKEND: pdx1-sub0-mail-a58 From: Nico Williams To: Robert Moskowitz Cc: "Salz, Rich" , "saag@ietf.org" Message-ID: <20200318155843.GH18021@localhost> References: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> <89121466-d091-5f22-a053-a2a618946908@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89121466-d091-5f22-a053-a2a618946908@htt-consult.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrudefjedgkeduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [saag] Perfect Forward Secrecy vs Forward Secrecy X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 15:58:56 -0000 On Wed, Mar 18, 2020 at 10:53:32AM -0400, Robert Moskowitz wrote: > On 3/18/20 10:48 AM, Salz, Rich wrote: > > Was the person who asked you to make the change a security person? > > A Sec AD. > > > Can you ask them for a rationale? > > His preference as, "perfection is hard to attain." The switch from calling it PFS to just FS came a long time ago -- I don't recall exactly, but it feels like roughly a decade ago. I'm not sure why, and "perfection is hard to attain" does seem a bit silly considering PFS is a term of art, but then, our terms of art get used by snake oil salespeople. Not that making one term of art harder to repurpose for snake oil sales -if that was the intent- will make much of a dent. But as you note, this ship has sailed. Nico -- From nobody Wed Mar 18 09:01:49 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2C93A17F2 for ; Wed, 18 Mar 2020 09:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=blackberry.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 lJtOjP9EKgw3 for ; Wed, 18 Mar 2020 09:01:44 -0700 (PDT) Received: from smtp-pc10.blackberry.com (smtp-pc10.blackberry.com [74.82.81.42]) (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 9D6C53A046E for ; Wed, 18 Mar 2020 09:01:43 -0700 (PDT) Received: from pps.filterd (mhs400cnc.rim.net [127.0.0.1]) by mhs400cnc.rim.net (8.16.0.27/8.16.0.27) with SMTP id 02IFmCw5179467; Wed, 18 Mar 2020 12:01:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blackberry.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp19; bh=VCWELMGijc/ImJ6/vIiy78SIrnSMfYrAPqL5oxgbVHw=; b=VH6t9S12wiUgc9sevhgJAXjX1LPEd1FfGvBH7abCfWUjLa2sAfOlv1+WklJJzQcM31OF ag6h+qmIppBxe97oVXRfZSKiVqhI1fOJTgm71kqVC0YdcUgbLJTBhHJsczNFrAQa6LXi uOJlaMCghNxudtcxTYskJ1O7q/2OUGUbW/O6TAWV0HhSlow+tWhvPMvZTtbzEetCQwSe AgK2psts9dBly96SPuKcs7QrESnn96ztLG+DqKdGktk9k6y0m6H9IWHSjOX9L0Fj9wgW E0MlF0yEx/fgW/80pm0Qg6L/IFHVjgvOaDJIWdxnSwoavjbnhj5/edTFv/RueSG49mHW HA== Received: from xch210cnc.rim.net (xch210cnc.rim.net [10.3.27.115]) by mhs400cnc.rim.net with ESMTP id 2yu1f02pyg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 18 Mar 2020 12:01:31 -0400 Received: from XCH210YKF.rim.net (10.2.27.110) by XCH210CNC.rim.net (10.3.27.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 18 Mar 2020 12:01:30 -0400 Received: from XCH210YKF.rim.net ([fe80::81ca:ad34:fc3:5ce8]) by XCH210YKF.rim.net ([fe80::81ca:ad34:fc3:5ce8%5]) with mapi id 15.01.1913.007; Wed, 18 Mar 2020 12:01:30 -0400 From: Dan Brown To: "Salz, Rich" , Robert Moskowitz , "saag@ietf.org" Thread-Topic: [saag] Perfect Forward Secrecy vs Forward Secrecy Thread-Index: AQHV/TKnv/elDdMNE0+7rke4G0Sq8ahOsTMAgAABcQCAAAHUAP//zF7w Date: Wed, 18 Mar 2020 16:01:30 +0000 Message-ID: <18624c8526f94f8892d80bb756e543c6@blackberry.com> References: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> <89121466-d091-5f22-a053-a2a618946908@htt-consult.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [100.64.97.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.645 definitions=2020-03-18_07:2020-03-18, 2020-03-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=721 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2003180074 Archived-At: Subject: Re: [saag] Perfect Forward Secrecy vs Forward Secrecy X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 16:01:47 -0000 Well, the paper https://eprint.iacr.org/2013/339.pdf does not use the term perfect, which I think is a good idea. Better to stop perpetuating a marketing word! Besides, forward secrecy has= not alternative meaning to worry about. FWIW, I once presented to a bunch of quantum computing researchers, and bli= thely used the term "perfect" to which they strenuously, and logically, obj= ected. Best regards, Dan > -----Original Message----- > From: saag On Behalf Of Salz, Rich > Sent: Wednesday, March 18, 2020 11:00 AM > To: Robert Moskowitz ; saag@ietf.org > Subject: Re: [saag] Perfect Forward Secrecy vs Forward Secrecy >=20 > > > Was the person who asked you to make the change a security person? >=20 > > A Sec AD. >=20 > That's disappointing. >=20 > > Why I feel this ship has sailed. >=20 > Agreed. >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_saag&d=3DDwICAg&c=3DyzoHOc_ZK-sxl- > kfGNSEvlJYanssXN3q-lhj0sp26wE&r=3DqkpbVDRj7zlSRVql- > UonsW647lYqnsrbXizKI6MgkEw&m=3D9ySHXHCknogS_OBxHFmfhiP5HybmGnP1 > ARI20jDHdxA&s=3DYAzeZGV0OLBWM983ddGInWmM4YdxVxg46aKgNpcLDEU&e > =3D ---------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From nobody Wed Mar 18 09:11:29 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFAE3A1808 for ; Wed, 18 Mar 2020 09:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, 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=cryptonector.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 CeTGuPnlX6jr for ; Wed, 18 Mar 2020 09:11:26 -0700 (PDT) Received: from buffalo.birch.relay.mailchannels.net (buffalo.birch.relay.mailchannels.net [23.83.209.24]) (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 5CC613A180C for ; Wed, 18 Mar 2020 09:11:26 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 035632091F; Wed, 18 Mar 2020 16:11:25 +0000 (UTC) Received: from pdx1-sub0-mail-a58.g.dreamhost.com (100-96-219-35.trex.outbound.svc.cluster.local [100.96.219.35]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 75BE220F82; Wed, 18 Mar 2020 16:11:24 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a58.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Wed, 18 Mar 2020 16:11:24 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Chemical-Spicy: 5032e0fd5564bafd_1584547884737_3091643758 X-MC-Loop-Signature: 1584547884737:1443711284 X-MC-Ingress-Time: 1584547884737 Received: from pdx1-sub0-mail-a58.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a58.g.dreamhost.com (Postfix) with ESMTP id DC38B7F57C; Wed, 18 Mar 2020 09:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=N91d4ij0E3ufeG K5VixmgwJDL6M=; b=uQVwSe6qlhcEydYLLUQfYhdY2ZdR8KmNfMIjotXPybnqE9 bjpp6U8DmPUW5oatGSbDjGTfCr60twzqgpXEh5CEDfaI0nGO3zg5hegUXsieeqmU exN0GCWIFHFY5z2ZxQhNYvf6N2syNG5JJYLoLrzVkSJm84NK4wQ2lUlq56DwQ= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a58.g.dreamhost.com (Postfix) with ESMTPSA id B21327F18E; Wed, 18 Mar 2020 09:11:04 -0700 (PDT) Date: Wed, 18 Mar 2020 11:10:56 -0500 X-DH-BACKEND: pdx1-sub0-mail-a58 From: Nico Williams To: Robert Moskowitz Cc: "Salz, Rich" , "saag@ietf.org" Message-ID: <20200318161055.GI18021@localhost> References: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> <89121466-d091-5f22-a053-a2a618946908@htt-consult.com> <20200318155843.GH18021@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200318155843.GH18021@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrudefjedgkedvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [saag] Perfect Forward Secrecy vs Forward Secrecy X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 16:11:28 -0000 ISTR it was Radia Perlman who told me, long ago, that we now call it FS, not PFS. But my memory of the chat where this came up long ago is very fuzzy. A brief search did not turn up anything specific. Of all the things to worry about today, changing terms of art is not very high on my list :/ From nobody Wed Mar 18 09:27:33 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B20B3A1858 for ; Wed, 18 Mar 2020 09:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=juniper.net header.b=YNIXAcMg; dkim=pass (1024-bit key) header.d=juniper.net header.b=QwrgHlip 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 4q-5tEVJWWLf for ; Wed, 18 Mar 2020 09:27:15 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 25EB23A184F for ; Wed, 18 Mar 2020 09:27:14 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 02IGNMaj026998; Wed, 18 Mar 2020 09:27:08 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=DawDlzuMMUOq1NUJ9cPdPDN4IOiox1+IJfhH7VnZAzs=; b=YNIXAcMgl7ECiZkytEpmkF3aEG4Pj12/aKsbyAjmEEtRZG4bhAQ2vkhDZWCrAjYd13Hv Vax2HfFZ4oAEjW71zVF53B1XgGrsKZxYiNwugKKVdU8btBwcGmGOWNS9oO1D7ECyI99f d1LNc2ad37Fo9onlRy8gN5IRuaJB2wYr8yJomg47dvcr1ZA5XVRGa03USTuwr3vCNLlj KRqraDSjZcmUALwcSoVEHSxH4kyH73qfE9NnqfYIDoa8UyAQVKE2Nrwa6ugc73zVEOlE fq97m1Jif5a4QUGWmn53dRuF9e3iY9WdhrXvmUQV6Cg1HUI8xBk2RTNxP87K6TlUFoQP TQ== Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2171.outbound.protection.outlook.com [104.47.58.171]) by mx0b-00273201.pphosted.com with ESMTP id 2yu9as9cjw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Mar 2020 09:27:08 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X1/OxXB9Xw+k1ieigsZwwIP+x2RRmjT3BGPahbvYTIpjmkSLkvvOUq4FeGXKFLa7WzfaZYJKBcymYgx7c5mahRIzMhTJdmvZ7IsPgllMId2+wTPIsC6YdqHnBy9vyQftbTxZRHN1Ii0PxMixlF4pPcVJVZxR49WLkiMQeNgnBOCtsoyrK9d+7w1sUrcQx/O3TNE9KxERVpzrDGOgsqqGwwXH0Af6qFeQeF7dOcTkZ+VZAtavnBxpl5fuHP9V/4GBeCxwg/rgaRJ39DusrwrBTkoyoxc3nJz4TsQTaNPlw3zBa1PlsHQAT/3eBfHwJeSTXBN3LOxRrdnm+nuPET8WkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DawDlzuMMUOq1NUJ9cPdPDN4IOiox1+IJfhH7VnZAzs=; b=UH8Usoy1OAXRjrDxDS2l6Sim9/g2CAgNld04E2/vlbeFup2T/xBUGDuDRy99eSiBEoiyTNSq1Tj4cZk6gidd6Cb7k779GRfmJHpa64uU9qzlquBI7R6BXyH5ccnZhOBttHPrDdrnA/At3gmqpIwxXzeuDBBNOmztSsBJKc3ela+3o0pxMjCZKUYRTL+YJf9kInqZD3P2Nd/RZqF+Vpru1nRNfjPDYHqRX2KYwONBlsQa1eCrN72wnLVVczyNToI/CCA2YGLN59Ht0C6ZrzsuVjR5h6rwIjdEZ50ASGeEv6RsmX+yZIXMKr7KbVBVs4KJCs62lTVSVhWlHVw2Sj1enw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.242.12) smtp.rcpttodomain=htt-consult.com smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DawDlzuMMUOq1NUJ9cPdPDN4IOiox1+IJfhH7VnZAzs=; b=QwrgHlipVe6TpsFyPo6gdXxtABFKxtmdnzZs8UtvavgGpAxEBRX06L1m5OQZZYEuxYWyIAGTOVnmnLOftkATKe/gsqAjZXygV8WgXlXXLk7DP172dOta77rF7bI91zse9iy58rY8X/JKEFM4hPjO2mhKKP/E7XJaJHQPw8NvJCk= Received: from MWHPR08CA0060.namprd08.prod.outlook.com (2603:10b6:300:c0::34) by DM5PR05MB3177.namprd05.prod.outlook.com (2603:10b6:3:c8::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.12; Wed, 18 Mar 2020 16:27:06 +0000 Received: from CO1NAM05FT026.eop-nam05.prod.protection.outlook.com (2603:10b6:300:c0:cafe::a0) by MWHPR08CA0060.outlook.office365.com (2603:10b6:300:c0::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.22 via Frontend Transport; Wed, 18 Mar 2020 16:27:05 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.242.12 as permitted sender) Received: from P-EXFEND-EQX-01.jnpr.net (66.129.242.12) by CO1NAM05FT026.mail.protection.outlook.com (10.152.96.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2814.6 via Frontend Transport; Wed, 18 Mar 2020 16:27:04 +0000 Received: from P-EXBEND-EQX-03.jnpr.net (10.104.8.56) by P-EXFEND-EQX-01.jnpr.net (10.104.8.54) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 18 Mar 2020 09:26:37 -0700 Received: from P-EXBEND-EQX-01.jnpr.net (10.104.8.52) by P-EXBEND-EQX-03.jnpr.net (10.104.8.56) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 18 Mar 2020 09:26:37 -0700 Received: from p-mailhub01.juniper.net (10.104.20.6) by P-EXBEND-EQX-01.jnpr.net (10.104.8.52) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 18 Mar 2020 09:26:37 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [10.160.0.88]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 02IGQYON022041; Wed, 18 Mar 2020 09:26:35 -0700 (envelope-from mdb@juniper.net) To: , Christopher Wood In-Reply-To: <6b73afd0-6eda-4533-a499-166934702f6e@www.fastmail.com> References: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> <6b73afd0-6eda-4533-a499-166934702f6e@www.fastmail.com> Comments: In-reply-to: "Christopher Wood" message dated "Wed, 18 Mar 2020 07:59:13 -0700." From: "Mark D. Baushke" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3516.1584548794.1@eng-mail01.juniper.net> Date: Wed, 18 Mar 2020 09:26:34 -0700 Message-ID: <3517.1584548794@eng-mail01.juniper.net> X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.242.12; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(4636009)(376002)(346002)(39860400002)(396003)(136003)(199004)(46966005)(26826003)(70586007)(5660300002)(70206006)(4326008)(7696005)(356004)(2906002)(478600001)(316002)(86362001)(47076004)(186003)(966005)(26005)(8936002)(81156014)(8676002)(426003)(336012)(110136005)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3177; H:P-EXFEND-EQX-01.jnpr.net; FPR:; SPF:SoftFail; LANG:en; PTR:InfoDomainNonexistent; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 996290c7-751e-4101-fb36-08d7cb59320e X-MS-TrafficTypeDiagnostic: DM5PR05MB3177: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6108; X-Forefront-PRVS: 03468CBA43 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: kGDMjrxaa9UF+Hh31rMCYqer8psVtZAQdFhVkXlnf01nbkDv23WohSX1SVFphiS/f7tPbUdzlOntqZCKcWHrxLYhhDwGUP4rXmO6ZNdNERfxCbDHhhP7UpRxT0YnLpnbXtUQjkxC9tUxZowo9JkNZwPs2YShRzhjQp0ZD96tXNUM92ljgLArc8bN6WZncJs4QnBAl/1zh50t1v+C2IXuR3obsQ/bbjv/KQ9KO9WZq+1heG7MbA/SR/SF+yglKqH+oI6icPPtWR7Y1rw6spLzcbB5wDYq29931Lpfe+WDM9tRp8/XAymSvFTuXLe7mA5+d3jQ/Uz8bUtZ5pnKJ/EqbT/eW2fOBx/JsMBmKB9JqFpFAKU8MM3Ud9HLNemPyBp9hGt/obU9+TfLrEcRjEhCayjrWwzCejIHv+dUDcTH/d70EhV6+sgHGy1UxVhfBnP/0nJyp0JU6l4Gj7bOR6QARlv5enRiDl1bH9UKV9auJgwcjZNlsw83AvOHXjmNeIkcCaYMzClvKsitwm5qSOyMhcE2KUxC2hA4UzLhgTvBWZwMyTMZU089kN+CnwxdelChC27E3V8weXO6H1zJSjMgLA== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Mar 2020 16:27:04.7535 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 996290c7-751e-4101-fb36-08d7cb59320e X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.242.12]; Helo=[P-EXFEND-EQX-01.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3177 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.645 definitions=2020-03-18_07:2020-03-18, 2020-03-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 lowpriorityscore=0 clxscore=1011 adultscore=0 mlxscore=0 impostorscore=0 bulkscore=0 suspectscore=0 malwarescore=0 phishscore=0 mlxlogscore=589 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003180075 Archived-At: Subject: Re: [saag] Perfect Forward Secrecy vs Forward Secrecy X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 16:27:27 -0000 Christopher Wood writes: > On Wed, Mar 18, 2020, at 7:48 AM, Salz, Rich wrote: > > I agree perfect forward secrecy is the term of art and we shouldn't > > create a new one. > > FWIW, +1. Wikipedia has an entry https://en.wikipedia.org/wiki/Forward_secrecy which begins with a quote from Menzies, Alfred; van Oorscot, Paul C.; Vanstone, SCOTT (1997). Handbook of Applied Cryptography. CRC Pres. ISBN 978-0-8493-8523-0. In cryptography, forward secrecy (FS), also known as perfect forward secrecy (PFS), is a feature of specific key agreement protocols that gives assurances that session keys will not be compromised even if the private key of the server is compromised. There is also https://www.perfectforwardsecrecy.com/ which has a paragraph Forward Secrecy has been used as a synonym for Perfect Forward Secrecy but there is a subtle difference between the two. Perfect Forward Secrecy has the additional property that an agreed key will not be compromised even if agreed keys derived from the same long-term keying material in a subsequent run are compromised. along with more justification of differences. So, I still think that PFS is a term of art and we should not stop using it. -- Mark From nobody Wed Mar 18 09:38:13 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BF03A1831 for ; Wed, 18 Mar 2020 09:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-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=icloud.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 bz6usP5g1_Xi for ; Wed, 18 Mar 2020 09:38:10 -0700 (PDT) Received: from pv50p00im-ztbu10011701.me.com (pv50p00im-ztbu10011701.me.com [17.58.6.53]) (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 2955B3A0138 for ; Wed, 18 Mar 2020 09:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1584549489; bh=yrHinqKGTQM1Kwf3il0+/X5j/21M6mcDpYJcwE0XYJM=; h=Content-Type:Subject:From:Date:Message-Id:To; b=yCz9xamFD/Yo53kHrSsVgcBnLrJ8kqxPhUul6FFWmQdRI+Cyg+1gvJPOSsW6pJru/ Vx+PD9nbT+X1eZH0eH7C9e7ehIuRZrkomxl2ZWtPXgGkrhM+ahRg/nawJeU/kNXwFf lQNRIIgNAUqrSm4dkebty9bjVipyjROYcTug/eRrcV4rxEAUsruQWtTur/edDUWXVz F/5eIoVR3tx/zuiLvQBWMi8/MiXaaS7f5LX7Hzxi2SlosZH0sRp9lpswXn/YH7co8P By/xq0yn5wXc+Fojkf00TNVaFwVQXvGtoJXbhoKHFSlEtuAEg45Xi1w0u2Nx7rYJQT ZRu8xccoTRlgg== Received: from [192.168.7.69] (thing1.merrymeet.com [173.164.244.99]) by pv50p00im-ztbu10011701.me.com (Postfix) with ESMTPSA id C7D1C8A01F1; Wed, 18 Mar 2020 16:38:08 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Jon Callas In-Reply-To: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> Date: Wed, 18 Mar 2020 09:38:07 -0700 Cc: Jon Callas , saag@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-03-18_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=916 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-2003180075 Archived-At: Subject: Re: [saag] Perfect Forward Secrecy vs Forward Secrecy X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 16:38:12 -0000 > On Mar 18, 2020, at 7:36 AM, Robert Moskowitz = wrote: >=20 > I have been asked to change all uses of the term: >=20 > Perfect Forward Secrecy to Forward Secrecy >=20 > What is the 'feel' about this. >=20 Please. +2^n. This is one of my peeves. Forward secrecy is a much better = term. Saying "perfect" forward secrecy is kinda like "military-grade" = encryption in the way it's misused, and often a shibboleth showing = trying to puff things up. In the face of "perfection" though, let me talk a bit out of the other = side of my mouth. The word "perfect" its most distilled form, means = something that can't be made better. Colloquially, we use it to mean = something like "flawless" but its most basic form is more like "best."=20= Most uses of Perfect Forward Secrecy meet neither of those. It's neither = flawless nor best. If one wants to rigorously define what "perfect" forward secrecy might = look like, "information-theoretic" security is pretty close to what = perfection is. It's not only rigorous, but it's got a lot of the = qualities you'd want in something "perfect." Well, we don't do that. We don't go to information-theoretic security. = The reason we don't, if you'll forgive the small hand wave is that we've = decided that 2^128 is a big number and moreover that it's big enough. At = the same time, for people who disagree, we offer them the number of = 2^256, and that's also a big enough number. We don't do "perfect" security in our fundamentals, because, as the = unnamed AD said, it's hard to achieve. If we look at a communications system, let me idealize something like = TLS into one, we do a key exchange of some object we turn into a key, = and then bulk encrypt with that key. The "PFS" systems we use could be = "better" (for some reasonable definition of better). Here's a sketch: There's nothing magic about forward secrecy. It only means you throw = keys away. We use one key for the whole session/transaction, and then = throw it away. (And yes, I am indeed burying a lot of detail.) Well, = could we make that better? If we can, then the existing system is not = perfect. It's easy to make it better -- negotiate two keys. Halfway through the = session, (hand wave, hand wave) negotiate a new key so that if a key is = compromised on one half, it doesn't compromise the other one. Take our = idealized handshake and just do it again. Can we do better than two keys? Sure! Four keys! Can we do better than = that? Yes. If you do a full handshake for every bit you transmit, then = *that* is the most forwardly-secret thing you can do. True Perfect = Forward Secrecy does a full handshake for every bit. We don't do that because it's hard, and also because it's kinda -- well, = gilding the lily is the kindest way to put it. This is where notions of = information-theoretic security come in. If you're doing a handshake with 2^128 bits of security, you can safely = transmit 128 bits under that handshake. You don't get more security by = sending only a single bit -- it's *better* but it's a difference without = distinction (cryptographically, it's a betterment without a = distingusher, hahaha). Thus, while True Perfect Forward secrecy does a = handshake for every bit, Operationally Perfect Forward Secrecy sends as = many bits as the security level of the handshake and no more. (=46rom this, we can also note that Truest Operationally Perfect Forward = Secrecy would do a handshake with a security level of a number of bits = that's the whole of the session, so you can send the whole thing in one = handshake. Note that when you do this, you don't actually need to have a = bulk cipher -- instead of doing "key exchange" we can just do "message = exchange.") We don't do anything like this. We don't because we have a collective, = unstated hunch that it's okay to use a key and send a lot. We even have = guidance and work on how big "a lot" should be. This is where = birthday-bounds issues, nonce issues, and so on all come in. (As usual, = yes, GCM, I'm looking at you.) Summing up, I kinda agree with the AD that "perfection is hard to = achieve" while going further that perfection is *undesirable* because it = carries with it a lot of baggage that we don't want to carry -- like the = baggage of doing handshakes. Most importantly and relevant, we should stop saying "perfect" because = it's false. At no point where we're doing forward secrecy are we = perfect. We could do better. We make the engineering decision to do Good = Enough Forward Secrecy.=20 Yes, yes, drop "Perfect." It should be just "Forward Secrecy" with no = editorializing, especially when it's just not true and even downright = misleading. Jon From nobody Wed Mar 18 09:39:14 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79983A184A for ; Wed, 18 Mar 2020 09:39:12 -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 OzbXiXk0eKNB for ; Wed, 18 Mar 2020 09:39:11 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 9F1913A0477 for ; Wed, 18 Mar 2020 09:39:10 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id s13so27820785ljm.1 for ; Wed, 18 Mar 2020 09:39:10 -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=14jX1kx1HdJVoYOi8ESpMhzp/clJCYVHxtZ3kBUjas8=; b=qAhG292FfVQ4irXinY7NLpPBeYZ53QhOR3DN03D0HjnFPZLup/SVJEDPDCyrdj/ek0 JeL5Xc+jFUhpwDwwyzS5TCAnP3dH53f9J6p3E4SbNMUbFTf5S6lSUpxjHFdeg4zApu9R TUo92VEBY9Lv9A3nAVyn0qh1Fw0mljDY+ma7etzBDpY+WKymJDh+mgNG7HOfuKy/Q5vv FadG855o0VjB9+4cPKfihDlvrxZT08jq/AFjzE3Ig2OmL742xgD1wIYEbsmZEyFnG6kM SY/xu7Bc0zi6hJquks7sohfIXY2xgGKW865JpzIVuylX2geMAJuKYJJivyl97cqScSMN ssuA== 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=14jX1kx1HdJVoYOi8ESpMhzp/clJCYVHxtZ3kBUjas8=; b=nSj0sqdQewwc3c72sL0rKzqXV7tcTB9Difn/7/Fev2DBWKXohOMhHeGp/2Ft5WzJF4 fG/+p0mxJOh4DCwvcMF5d16P8QNSZld3mmEbCO/Wt35cLbTjXa4It19zisE0EkXrQqiu L83Q1t8S8tc4r9DjQ2uNmtKlDfCJWD+bi8osl3P7nQGvM0zQ5UJHVhcyy7zqcdqLhHgP iWgDq96beJY43f2aGfKv5hKy4EqJp9eZw3ezSzTSftTqEuZpziO2LmBhYd297XX/dUFN OD5ADbJrzxC9AD0xL8sGwwAfG7a8+ovBouhk5J94l+Lzl+RvclSfgr5oGfc7Hg3CGLtc nUXg== X-Gm-Message-State: ANhLgQ2xYsCxAkXdRHiaU/I62wkc7eLqnZMVVZoE4095So29n4twaP7O /9ajHrKuUPxIO5WN2g4xlerLSAn0YvpDIZFHhWCdnNVv8zhOOg== X-Google-Smtp-Source: ADFU+vu85DL7VLNot9Icduiorzkb5mf487PR3EEYpdgpHbzanl/Dq4WP0fQSaZOp9MIgF58/RzbuVSXGw/b6gZuwQGI= X-Received: by 2002:a2e:8246:: with SMTP id j6mr2407826ljh.162.1584549548768; Wed, 18 Mar 2020 09:39:08 -0700 (PDT) MIME-Version: 1.0 References: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> <6b73afd0-6eda-4533-a499-166934702f6e@www.fastmail.com> <3517.1584548794@eng-mail01.juniper.net> In-Reply-To: <3517.1584548794@eng-mail01.juniper.net> From: Eric Rescorla Date: Wed, 18 Mar 2020 09:38:32 -0700 Message-ID: To: "Mark D. Baushke" Cc: saag@ietf.org, Christopher Wood Content-Type: multipart/alternative; boundary="000000000000fbd19a05a123b0dc" Archived-At: Subject: Re: [saag] Perfect Forward Secrecy vs Forward Secrecy X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 16:39:13 -0000 --000000000000fbd19a05a123b0dc Content-Type: text/plain; charset="UTF-8" I don't feel strongly about this, but would make three points: 1. RFC 4949 seems to have both terms, with the main definition under PFS and FS pointing to PFS and then says: Ordinary forward secrecy vs. "perfect" forward secret: Experts disagree about the difference between these two. Some say there is no difference, and some say that the initial naming was unfortunate and suggest dropping the word "perfect". Some suggest using "forward secrecy" for the case where one long-term private key is compromised, and adding "perfect" for when both private keys (or, when the protocol is multi-party, all private keys) are 2. TLS 1.3 explicitly chose to use the term "forward secret" and not "perfect forward secret". 3. One advantage of saying FS and not PFS is that you can then describe things as "forward secret" in a way that isn't grammatically awkward, as in RFC 8446; S 2.3. 1. This data is not forward secret, as it is encrypted solely under keys derived using the offered PSK. -Ekr On Wed, Mar 18, 2020 at 9:30 AM Mark D. Baushke wrote: > Christopher Wood writes: > > > On Wed, Mar 18, 2020, at 7:48 AM, Salz, Rich wrote: > > > I agree perfect forward secrecy is the term of art and we shouldn't > > > create a new one. > > > > FWIW, +1. > > Wikipedia has an entry > > https://en.wikipedia.org/wiki/Forward_secrecy > > which begins with a quote from > > Menzies, Alfred; van Oorscot, Paul C.; Vanstone, SCOTT (1997). > Handbook of Applied Cryptography. CRC Pres. ISBN 978-0-8493-8523-0. > > In cryptography, forward secrecy (FS), also known as perfect > forward secrecy (PFS), is a feature of specific key agreement > protocols that gives assurances that session keys will not be > compromised even if the private key of the server is compromised. > > There is also https://www.perfectforwardsecrecy.com/ which has a paragraph > > Forward Secrecy has been used as a synonym for Perfect Forward > Secrecy but there is a subtle difference between the two. Perfect > Forward Secrecy has the additional property that an agreed key > will not be compromised even if agreed keys derived from the same > long-term keying material in a subsequent run are compromised. > > along with more justification of differences. > > So, I still think that PFS is a term of art and we should not stop using > it. > > -- Mark > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --000000000000fbd19a05a123b0dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't feel strongly about this, but would make three= points:

1. RFC 4949 seems to have both terms, with the main
defi= nition under PFS and FS pointing to PFS and then says:

=C2=A0 =C2=A0= Ordinary forward secrecy vs. "perfect" forward secret: Experts=C2=A0 =C2=A0disagree about the difference between these two. Some say the= re is no
=C2=A0 =C2=A0difference, and some say that the initial naming w= as unfortunate and
=C2=A0 =C2=A0suggest dropping the word "perfect&= quot;. Some suggest using "forward
=C2=A0 =C2=A0secrecy" for t= he case where one long-term private key is compromised,
=C2=A0 =C2=A0and= adding "perfect" for when both private keys (or, when the
=C2= =A0 =C2=A0protocol is multi-party, all private keys) are


2. TLS = 1.3 explicitly chose to use the term "forward secret" and not
= "perfect forward secret".

3. One advantage of saying FS an= d not PFS is that you can then describe
things as "forward secret&q= uot; in a way that isn't grammatically awkward,
as in RFC 8446; S 2.= 3.

=C2=A0 =C2=A01.=C2=A0 This data is not forward secret, as it is e= ncrypted solely under
=C2=A0 =C2=A0 =C2=A0 =C2=A0keys derived using the = offered PSK.


-Ekr

On Wed, Mar 18, 2020 at 9:30 AM Mark D. Bau= shke <mdb=3D40juniper.ne= t@dmarc.ietf.org> wrote:
Christopher Wood <caw@heapingbits.net> writes:

> On Wed, Mar 18, 2020, at 7:48 AM, Salz, Rich wrote:
> > I agree perfect forward secrecy is the term of art and we shouldn= 't
> > create a new one.
>
> FWIW, +1.

Wikipedia has an entry

=C2=A0 https://en.wikipedia.org/wiki/Forward_secrecy

which begins with a quote from

=C2=A0 Menzies, Alfred; van Oorscot, Paul C.; Vanstone, SCOTT (1997).
=C2=A0 Handbook of Applied Cryptography. CRC Pres. ISBN 978-0-8493-8523-0.<= br>
=C2=A0 =C2=A0 =C2=A0 In cryptography, forward secrecy (FS), also known as p= erfect
=C2=A0 =C2=A0 =C2=A0 forward secrecy (PFS), is a feature of specific key ag= reement
=C2=A0 =C2=A0 =C2=A0 protocols that gives assurances that session keys will= not be
=C2=A0 =C2=A0 =C2=A0 compromised even if the private key of the server is c= ompromised.

There is also https://www.perfectforwardsecrecy.com/ which= has a paragraph

=C2=A0 =C2=A0 =C2=A0 Forward Secrecy has been used as a synonym for Perfect= Forward
=C2=A0 =C2=A0 =C2=A0 Secrecy but there is a subtle difference between the t= wo. Perfect
=C2=A0 =C2=A0 =C2=A0 Forward Secrecy has the additional property that an ag= reed key
=C2=A0 =C2=A0 =C2=A0 will not be compromised even if agreed keys derived fr= om the same
=C2=A0 =C2=A0 =C2=A0 long-term keying material in a subsequent run are comp= romised.

along with more justification of differences.

So, I still think that PFS is a term of art and we should not stop using it.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mark

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--000000000000fbd19a05a123b0dc-- From nobody Wed Mar 18 09:46:02 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37D83A1886 for ; Wed, 18 Mar 2020 09:45:57 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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=heapingbits.net header.b=UbDDXAnB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=0DxK3vi1 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 mWAE_KaQcaLg for ; Wed, 18 Mar 2020 09:45:56 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 688183A187E for ; Wed, 18 Mar 2020 09:45:56 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F14055C0200; Wed, 18 Mar 2020 12:45:54 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 18 Mar 2020 12:45:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm3; bh= XHLMSGTtyMc5EI//O5gw6oJgbmKydcqF5Yg5tU+KsiE=; b=UbDDXAnBvTqB7KI2 oaavVyIsiMtTHYaowXfrtLxnQXYN2WqHT1wGqLMIvBs/gIvcmHjN+ZPsuZ64tm5D 6z0kePVII45Szcfxc7yMLtk2ie6/21gsxgrchezYtBYh0Wmt5w5wiexO8vGOhqmc FhDHbC4fkK5bEqt79xXcjCvHud9i3/QrG6iPnOO/wOGCDgBS/vRTRqPbED9vwKHL q9g1Y8h6RtgNOQEFw0lPHx9t7ICHtlLQD6cOyvfflgtYAxui7iyYutthza+MaQK6 flBJoxYInsTVuZGgmRpkqLZfaNRQKPdvk+/DaA1Cbld3aN1006zo+NTShtN1nBMG Nr/9Pg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=XHLMSGTtyMc5EI//O5gw6oJgbmKydcqF5Yg5tU+Ks iE=; b=0DxK3vi1fgo8nUywBVCAefQ2mRSkobLycRlsec1VOGT15vIl45f+WA7kZ 2u0LInTY1UCne5aq7B/WqHH4LA/FlnzVWZlQAnmFmzaHzOAZqdE5ZMznydVVEjF5 z/nG9yRdf++XHYdFtteY6tgZf/Z+LJdvDU6ijo6Q5LowTdS8SoGsfsuTuG8FD+Yv +/5mQvZ35BR6THdGrahT/1ab5BBsFnHXV3rt6uUWPR5qU3FoHZySuSc2lHO/PHxw oDkf1MzJyDOB/KFdAwCOPp3IE0JyQ2ctl9WUzGPzYFxb2R44xbwrAv2PftUlIiZc Wr1+jT3tPZZVD33Kkvcdm/utRjo9g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudefjedgkeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffokfgjfhggtgfgsehtke hmtdertdejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucfkphepjeefrdelvddrieegrddufedtne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheptggrfies hhgvrghpihhnghgsihhtshdrnhgvth X-ME-Proxy: Received: from [10.0.0.184] (c-73-92-64-130.hsd1.ca.comcast.net [73.92.64.130]) by mail.messagingengine.com (Postfix) with ESMTPA id 7ED633061DC5; Wed, 18 Mar 2020 12:45:53 -0400 (EDT) From: "Christopher Wood" To: "Eric Rescorla" Cc: "Mark D. Baushke" , saag@ietf.org Date: Wed, 18 Mar 2020 09:45:52 -0700 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: References: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> <6b73afd0-6eda-4533-a499-166934702f6e@www.fastmail.com> <3517.1584548794@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [saag] Perfect Forward Secrecy vs Forward Secrecy X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 16:45:58 -0000 On 18 Mar 2020, at 9:38, Eric Rescorla wrote: > I don't feel strongly about this, but would make three points: > > 1. RFC 4949 seems to have both terms, with the main > definition under PFS and FS pointing to PFS and then says: > > Ordinary forward secrecy vs. "perfect" forward secret: Experts > disagree about the difference between these two. Some say there is > no > difference, and some say that the initial naming was unfortunate > and > suggest dropping the word "perfect". Some suggest using "forward > secrecy" for the case where one long-term private key is > compromised, > and adding "perfect" for when both private keys (or, when the > protocol is multi-party, all private keys) are > > > 2. TLS 1.3 explicitly chose to use the term "forward secret" and not > "perfect forward secret". > > 3. One advantage of saying FS and not PFS is that you can then > describe > things as "forward secret" in a way that isn't grammatically awkward, > as in RFC 8446; S 2.3. > > 1. This data is not forward secret, as it is encrypted solely > under > keys derived using the offered PSK. All good points! I based my opinion on the HAC definition, though Jon’s response nudged me the other way. (Thanks, Jon!) From nobody Wed Mar 18 09:47:34 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD863A1889 for ; Wed, 18 Mar 2020 09:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, 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=cryptonector.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 3nb7W_z0YkEY for ; Wed, 18 Mar 2020 09:47:31 -0700 (PDT) Received: from caracal.birch.relay.mailchannels.net (caracal.birch.relay.mailchannels.net [23.83.209.30]) (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 D36143A187C for ; Wed, 18 Mar 2020 09:47:30 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 1D86750225E; Wed, 18 Mar 2020 16:47:30 +0000 (UTC) Received: from pdx1-sub0-mail-a58.g.dreamhost.com (100-96-215-21.trex.outbound.svc.cluster.local [100.96.215.21]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 37CA6502233; Wed, 18 Mar 2020 16:47:29 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a58.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Wed, 18 Mar 2020 16:47:29 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Illustrious-Well-Made: 210b9ff7489e2b63_1584550049548_2975449001 X-MC-Loop-Signature: 1584550049548:2978610861 X-MC-Ingress-Time: 1584550049546 Received: from pdx1-sub0-mail-a58.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a58.g.dreamhost.com (Postfix) with ESMTP id B31DB7F55F; Wed, 18 Mar 2020 09:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Hw1nj+2izdnoVe LBtrr2DcE4hvY=; b=aZtil7deOxOKDWZM/HMLHwPiERDsrQmF5kMJQoXQrQG6hy 8JIvSojsMjHnJyEOd+8e245IUdzDb2S2cXaTzB5fgsfDta4inXAUfxm7oK6nfy0o yhOu79D/lMmEFoIEVPv5OwLAQaxQ6OXtt1p0p62D5liHzPM5a2Rv5rRFtdR/U= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a58.g.dreamhost.com (Postfix) with ESMTPSA id 17DFD7F1B7; Wed, 18 Mar 2020 09:47:22 -0700 (PDT) Date: Wed, 18 Mar 2020 11:47:20 -0500 X-DH-BACKEND: pdx1-sub0-mail-a58 From: Nico Williams To: "Mark D. Baushke" Cc: saag@ietf.org, Christopher Wood Message-ID: <20200318164718.GJ18021@localhost> References: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> <6b73afd0-6eda-4533-a499-166934702f6e@www.fastmail.com> <3517.1584548794@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3517.1584548794@eng-mail01.juniper.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrudefjedgledtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecuffhomhgrihhnpehpvghrfhgvtghtfhhorhifrghrughsvggtrhgvtgihrdgtohhmnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Archived-At: Subject: Re: [saag] Perfect Forward Secrecy vs Forward Secrecy X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 16:47:33 -0000 On Wed, Mar 18, 2020 at 09:26:34AM -0700, Mark D. Baushke wrote: > Menzies, Alfred; van Oorscot, Paul C.; Vanstone, SCOTT (1997). > Handbook of Applied Cryptography. CRC Pres. ISBN 978-0-8493-8523-0. > > In cryptography, forward secrecy (FS), also known as perfect > forward secrecy (PFS), is a feature of specific key agreement > protocols that gives assurances that session keys will not be > compromised even if the private key of the server is compromised. > > There is also https://www.perfectforwardsecrecy.com/ which has a paragraph > > Forward Secrecy has been used as a synonym for Perfect Forward > Secrecy but there is a subtle difference between the two. Perfect > Forward Secrecy has the additional property that an agreed key > will not be compromised even if agreed keys derived from the same > long-term keying material in a subsequent run are compromised. > > along with more justification of differences. Are there examples in Internet protocols of FS key agreement protocols that aren't also PFS? I'm not denying that it's possible to construct an FS-but-not-PFS key agreement protocols, but I'm wondering whether we need a name for those when we wouldn't want to have any of them. Nico -- From nobody Wed Mar 18 10:16:58 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990D93A18FF for ; Wed, 18 Mar 2020 10:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6NskRRkUlC-K for ; Wed, 18 Mar 2020 10:16:54 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2065.outbound.protection.outlook.com [40.107.22.65]) (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 A00723A18F9 for ; Wed, 18 Mar 2020 10:16:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZupDUXAJ1+VzyyCo0uWbEnfi27QfOEpj9QpxpZ9y84m33MrqJ3pEo03WEHPPSiZTomOI758fJbCrmXM9Wd9WWuNZtmqJclkT7GWza4cBYO4PAgtSggQyIuYEnDq673buKFIqOxqnrnC0/9Hdj2Qy/4Bjy8bGwOx3a7Gust3b0LPg6qD2sCACen3DcfQvG7ev0i66a5KHjRu8iupfUZijw64A6AIISUrs24Nrvqmr8emmSa8YYv5RZmNTPxiEbS+7ZInjP4Rk1Dok4EgNioYgp8y4njUyaOf3mokiqqayTOD5hdUK5Z45CuCzsUBGWVBVWfZsjvuOcYQuS8RuIvOyCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E9tej+1mv0TUR8zLhkNtIHbsi3T4jnMlMCMT0xgq7gg=; b=dJOWIVZvrhraGpv9dE3XkUWewGvzzf77SOVyScRui3GpNmjLDzRiLy4hJAg9DEMJs8GN6fvq2hv7xzTP6SowscSQqLuggrMLcRwwPUfM+zany79svuYEnTzbQVI84xEeZqHkOih3FxznyP3BFOGutHIS4GaKr7Y9Uwv2ajKnirSnoj14YPzkFPPLIgIpHVWqNSVvNe1s2yjdpwKwod9s/ojZGclQujEb2jDFnohpW99snkHWgjlXUhqPdPHVUOQ9KAAuGNQtyVCh/Y6itKTjOfd4MauRBpgXgyv/Bge2CVNBnlENMcnjY1qr12GiYqlXBmopzaRikDthxK0A3PKg7g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=warwick.ac.uk; dmarc=pass action=none header.from=warwick.ac.uk; dkim=pass header.d=warwick.ac.uk; arc=none Received: from DB7PR01MB5435.eurprd01.prod.exchangelabs.com (20.178.104.28) by DB7PR01MB4774.eurprd01.prod.exchangelabs.com (20.177.122.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.18; Wed, 18 Mar 2020 17:16:51 +0000 Received: from DB7PR01MB5435.eurprd01.prod.exchangelabs.com ([fe80::8586:99b1:9fc5:9a93]) by DB7PR01MB5435.eurprd01.prod.exchangelabs.com ([fe80::8586:99b1:9fc5:9a93%7]) with mapi id 15.20.2835.017; Wed, 18 Mar 2020 17:16:51 +0000 From: "Hao, Feng" To: Nico Williams , Robert Moskowitz CC: "saag@ietf.org" Thread-Topic: [saag] Perfect Forward Secrecy vs Forward Secrecy Thread-Index: AQHV/TKuVIynJFZorEOTviReKuT/F6hObiUAgAABcQCAABI5gIAAFdEA Date: Wed, 18 Mar 2020 17:16:51 +0000 Message-ID: <949B71B6-87CD-4AF1-A7F7-7CC196CCA2ED@warwick.ac.uk> References: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> <89121466-d091-5f22-a053-a2a618946908@htt-consult.com> <20200318155843.GH18021@localhost> In-Reply-To: <20200318155843.GH18021@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.13.200210 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Feng.Hao@warwick.ac.uk; x-originating-ip: [86.1.47.16] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8a479765-b7c3-4b52-cc6a-08d7cb602639 x-ms-traffictypediagnostic: DB7PR01MB4774: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(366004)(346002)(136003)(376002)(199004)(71200400001)(86362001)(6486002)(6512007)(2906002)(5660300002)(91956017)(76116006)(966005)(66446008)(66476007)(64756008)(66946007)(66556008)(33656002)(36756003)(6506007)(53546011)(478600001)(110136005)(786003)(316002)(4326008)(26005)(186003)(2616005)(81156014)(81166006)(8936002)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR01MB4774; H:DB7PR01MB5435.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: warwick.ac.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ydlA861wAbz9xvfeaNg5IgQphKoSdZo3C7sXrwWaYVo99PbPlWT0k7Ak2cq1wF4GXiqUU1lHB9PZ8LMGCi+SuH30n2parbcKx85O2DKFxPEe7fckZCV8ymZOl4pW9Ky2Sx0j0U02EieLvWIysOaAO6pkQVTWDprjD5LUVwi2Bl2UO/69Itwd6HH5XZLEeBO4pg7+zpO0el/24Yemhr39lNF0E1h4Hce3n/1iQJnJIIzRW7C3KKAbY4JgUh1lk6UZIENY8vmJASPwevr5B2cFw6EFtSV6O1WKWNMok0G2Cr/2eJJY5lA8egebxZpXkpd32J/FzODaO8KoQXyZHmspKeg1gfxtJ5hJ/iShGuMhfaW+rZ0qGSsJgqYF9EFo3gbk9hpvRCR+jfYJ0o4eOtW9lXUH/aCYOayHPqEABW6y53vdKO60N2XZpiqYpAcfLu0d4nSRoMaylI1Jh/WX2wI4WrBEmnUwOt2+GU1kqdD+XvYjQl1f06AK5nEPVJo2qplJkFVTuXJM61PTgo7f6haKZg== x-ms-exchange-antispam-messagedata: ks1c/EIDinKKBx0892uY5GOIUBTDKJ65OJ7faqOK0v/pt3ExgbzYyHKDvLO/4rX/dzXE+PQrnGrzjF3linYsc/9RbZj35gVfiFDV4dIWLRaYX7oh+2hCcZkbxR0viHj91DJBPhArlb0SaUTr+60wNg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: warwick.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 8a479765-b7c3-4b52-cc6a-08d7cb602639 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2020 17:16:51.0497 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 09bacfbd-47ef-4465-9265-3546f2eaf6bc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: R7cR+TJXxLAR+lwO9E27fCG1Y0JfCktcrrhyIrGIeAAS5640AmThqCgGqyOaiUbFbY5JTocPEVZzlvlSWP6idFzUowcZQmT+gWrrQOuMXrY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR01MB4774 Archived-At: Subject: Re: [saag] Perfect Forward Secrecy vs Forward Secrecy X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 17:16:56 -0000 VGhlIHVzZSBvZiBQRlMgaXMgdmVyeSBwcmV2YWxlbnQgaW4gdGhlIHBhc3QgbGl0ZXJhdHVyZSBv biBrZXkgZXhjaGFuZ2UuIEluIDIwMTAsIHdoZW4gSSB3YXMgd29ya2luZyBvbiB0aGUgWUFLIHBy b3RvY29sIFsxXSwgSSBkaWQgd29uZGVyIHdoeSB0aGUgdGVybSBQRlMgd2FzIHVzZWQgZXZlcnl3 aGVyZSBkZXNwaXRlIHRoYXQgdGhlIHdvcmQgInBlcmZlY3QiIG9idmlvdXNseSBoYXMgbm8gY29u Y3JlYXRlIG1lYW5pbmcuIEF0IHRoZSB0aW1lIEkgZm91bmQgdGhlIHZlcnkgZmV3IHBhcGVycyB0 aGF0IHN1Z2dlc3QgdGhlIHdvcmQgInBlcmZlY3QiIGluIFBGUyBpcyByZWR1bmRhbnQgYXJlIE1R ViBwYXBlcnMgKDE5OTgsIGFuZCB0aGUgbGF0ZXIgMjAwMyBqb3VybmFsIHZlcnNpb24pLiBJbiBb MV0sIEkgZXhwbGljaXRseSBkcm9wcGVkIHRoZSB3b3JkICJwZXJmZWN0IiBmcm9tIFBGUyBhcyBp dCByZWFsbHkgaGFzIG5vIGNvbmNyZXRlIG1lYW5pbmcuIEJ1dCB3aXRoaW4gdGhlIGNvbnRleHQg b2YgdGhlIHByb3RvY29sIHRoYXQgSSB3YXMgZGVzaWduaW5nLCBJIGRlZmluZWQgaGFsZi9mdWxs IGZvcndhcmQgc2VjcmVjeSB0byBleHBsaWNpdGx5IGRpc3Rpbmd1aXNoIHRoZSB0d28gY2FzZXMg dGhhdCB3aGVuIG9uZSBvciBib3RoIHBhcnRpZXMnIHN0YXRpYyBrZXlzIGFyZSBjb21wcm9taXNl ZC4gDQoNClsxXSBodHRwczovL2VwcmludC5pYWNyLm9yZy8yMDEwLzEzNi5wZGYNCg0KQ2hlZXJz LA0KRmVuZw0KDQrvu79PbiAxOC8wMy8yMDIwLCAxNTo1OSwgInNhYWcgb24gYmVoYWxmIG9mIE5p Y28gV2lsbGlhbXMiIDxzYWFnLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIG5pY29AY3J5 cHRvbmVjdG9yLmNvbT4gd3JvdGU6DQoNCiAgICBPbiBXZWQsIE1hciAxOCwgMjAyMCBhdCAxMDo1 MzozMkFNIC0wNDAwLCBSb2JlcnQgTW9za293aXR6IHdyb3RlOg0KICAgID4gT24gMy8xOC8yMCAx MDo0OCBBTSwgU2FseiwgUmljaCB3cm90ZToNCiAgICA+ID4gV2FzIHRoZSBwZXJzb24gd2hvIGFz a2VkIHlvdSB0byBtYWtlIHRoZSBjaGFuZ2UgYSBzZWN1cml0eSBwZXJzb24/DQogICAgPiANCiAg ICA+IEEgU2VjIEFELg0KICAgID4gDQogICAgPiA+IENhbiB5b3UgYXNrIHRoZW0gZm9yIGEgcmF0 aW9uYWxlPw0KICAgID4gDQogICAgPiBIaXMgcHJlZmVyZW5jZSBhcywgInBlcmZlY3Rpb24gaXMg aGFyZCB0byBhdHRhaW4uIg0KICAgIA0KICAgIFRoZSBzd2l0Y2ggZnJvbSBjYWxsaW5nIGl0IFBG UyB0byBqdXN0IEZTIGNhbWUgYSBsb25nIHRpbWUgYWdvIC0tIEkNCiAgICBkb24ndCByZWNhbGwg ZXhhY3RseSwgYnV0IGl0IGZlZWxzIGxpa2Ugcm91Z2hseSBhIGRlY2FkZSBhZ28uICBJJ20gbm90 DQogICAgc3VyZSB3aHksIGFuZCAicGVyZmVjdGlvbiBpcyBoYXJkIHRvIGF0dGFpbiIgZG9lcyBz ZWVtIGEgYml0IHNpbGx5DQogICAgY29uc2lkZXJpbmcgUEZTIGlzIGEgdGVybSBvZiBhcnQsIGJ1 dCB0aGVuLCBvdXIgdGVybXMgb2YgYXJ0IGdldCB1c2VkIGJ5DQogICAgc25ha2Ugb2lsIHNhbGVz cGVvcGxlLg0KICAgIA0KICAgIE5vdCB0aGF0IG1ha2luZyBvbmUgdGVybSBvZiBhcnQgaGFyZGVy IHRvIHJlcHVycG9zZSBmb3Igc25ha2Ugb2lsIHNhbGVzDQogICAgLWlmIHRoYXQgd2FzIHRoZSBp bnRlbnQtIHdpbGwgbWFrZSBtdWNoIG9mIGEgZGVudC4gIEJ1dCBhcyB5b3Ugbm90ZSwNCiAgICB0 aGlzIHNoaXAgaGFzIHNhaWxlZC4NCiAgICANCiAgICBOaWNvDQogICAgLS0gDQogICAgDQogICAg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBzYWFn IG1haWxpbmcgbGlzdA0KICAgIHNhYWdAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NhYWcNCiAgICANCg0K From nobody Wed Mar 18 10:18:18 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607A93A18F2 for ; Wed, 18 Mar 2020 10:18:16 -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 LfzqlBRZ3Gs4 for ; Wed, 18 Mar 2020 10:18:14 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 C1DCD3A0872 for ; Wed, 18 Mar 2020 10:18:13 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id g12so27991577ljj.3 for ; Wed, 18 Mar 2020 10:18:13 -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=xQv9AnvPp5IGut8vpJdoR2FKD46B9hh8ZtnFfmynEwM=; b=i1N4WAzCHU7imB1y/HEZPJnRtXrYvqPUA9wIrP8mc4RuhueVy49YXjskxl5Egt7WEt 1fK1YBpnI7OUEgqC4YwbMG8nRk8HFoPDWLrpiHp0a2xMJwj3t/ozlDm/x//s6iy+e9KL cqAKz+UAap+I58iRZ+L+XjKoZLAo3GIVN9D9KX0iFR+YaiL7v/s3KYS/pIfmszR9B72b m3ErkLJ/TJ7lypdmC050YXbnev0BJrLMYiT2n6g7WFZ3yc16e/joZu2QbdAfsqe0i8N4 3CoiOJZ5ar1G5xglC7FINQ8ZifoUm7csr11OEvePkyQTvEoZ+BGqXWlr0+vJL/f+aGbn 00SQ== 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=xQv9AnvPp5IGut8vpJdoR2FKD46B9hh8ZtnFfmynEwM=; b=t1mwS+IxizMTjA4cNU8SqWaRL3UdqjZluEmonXoftbt2k0ptupfGVF8OXcLFR0IlYS l7YTd36bfLywtps52FSEF7GNDprLGjW3cMM94eEogXSfBi/pBjF4kg4pEnZG5EtkZgxX EwClk0TbQNqR0mwikglpKVu+mqr86ZScMpYjvPO0oGMaQ2LX4+1Serpq0d/x4zMlDWk6 Q5HozdldqCk9HYS/K4ShI3xdspEsU2sMOdenLHQce5iBHs6XeXAws8z6pJEsp21cs252 IBnEw9pik9rhsHgM4yKScKSO35uVgbzDF5TvL344bx0U6uVhC4zRyLIgrs4Ung9BVNN2 fXeg== X-Gm-Message-State: ANhLgQ25o+baHFNwe7tPSFZsMEUNr5AhXqhFkXDO9MqRf0gi5PWzwcSw LfQFt9LInHqiwFPEZbiMsgfEpXBGRgmsjjRlS5dR8crBx5Jlhg== X-Google-Smtp-Source: ADFU+vvnGC/PwWo4AzaMBA1C4oIhYgFBJFtBx8OaMAdXkWl8/Fryu7U/V+/FcBa+m2d979VH+17P4BaCtBzFHu1ipgY= X-Received: by 2002:a2e:908f:: with SMTP id l15mr2879998ljg.120.1584551892042; Wed, 18 Mar 2020 10:18:12 -0700 (PDT) MIME-Version: 1.0 References: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> <6b73afd0-6eda-4533-a499-166934702f6e@www.fastmail.com> <3517.1584548794@eng-mail01.juniper.net> <20200318164718.GJ18021@localhost> In-Reply-To: <20200318164718.GJ18021@localhost> From: Eric Rescorla Date: Wed, 18 Mar 2020 10:17:35 -0700 Message-ID: To: Nico Williams Cc: "Mark D. Baushke" , saag@ietf.org Content-Type: multipart/alternative; boundary="000000000000a75f0d05a1243c71" Archived-At: Subject: Re: [saag] Perfect Forward Secrecy vs Forward Secrecy X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 17:18:17 -0000 --000000000000a75f0d05a1243c71 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 18, 2020 at 9:47 AM Nico Williams wrote: > On Wed, Mar 18, 2020 at 09:26:34AM -0700, Mark D. Baushke wrote: > > Menzies, Alfred; van Oorscot, Paul C.; Vanstone, SCOTT (1997). > > Handbook of Applied Cryptography. CRC Pres. ISBN 978-0-8493-8523-0. > > > > In cryptography, forward secrecy (FS), also known as perfect > > forward secrecy (PFS), is a feature of specific key agreement > > protocols that gives assurances that session keys will not be > > compromised even if the private key of the server is compromised. > > > > There is also https://www.perfectforwardsecrecy.com/ which has a > paragraph > > > > Forward Secrecy has been used as a synonym for Perfect Forward > > Secrecy but there is a subtle difference between the two. Perfect > > Forward Secrecy has the additional property that an agreed key > > will not be compromised even if agreed keys derived from the same > > long-term keying material in a subsequent run are compromised. > > > > along with more justification of differences. > > Are there examples in Internet protocols of FS key agreement protocols > that aren't also PFS? I'm not denying that it's possible to construct an > FS-but-not-PFS key agreement protocols, but I'm wondering whether we > need a name for those when we wouldn't want to have any of them. > I've honestly never seen this particular distinction of FS vs. PFS drawn and I'm not quite sure it's that useful. Consider the case of a typical SIGMA-based AKE like TLS. The handshake protocol typically spits out one piece of shared entropy (e.g., the TLS 1.2 master secret) which is then key expanded into multiple working (traffic) keys. Assuming a strong KDF, then generally working key A cannot be used to derive working key B. However, the MS can be used to derive A or B. So is this PFS or just FS? Depends on where you draw the line for "agreed key", right? To make things more complicated, when you have a protocol that offers resumption (as with TLS) you have to be able to talk about the FS properties of resumed data, which may be different from those of the rest of the data. As a concrete example: - In TLS 1.2, you need to store the MS as long as you want resumption, which means that compromise of the session database at time T2 also compromises stored sessions from time T1 < T. - In TLS 1.3, the resumption master secret is different from the MS, so compromise at T2 doesn't compromise T1 if you use a session database and delete promptly. However if you use session tickets, then the STK threatens PFS. So in this case, it's not even a property of the AKE. ISTM that using "perfect" or not doesn't convey enough info and we should instead talk about protocols being forward secure with respect to certain attacks (as is the case in MLS). See for instance: https://tools.ietf.org/rfcmarkup?doc=8446#section-8.1 -Ekr --000000000000a75f0d05a1243c71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 18, 2020 at 9:47 AM Nico = Williams <nico@cryptonector.com= > wrote:
= On Wed, Mar 18, 2020 at 09:26:34AM -0700, Mark D. Baushke wrote:
>=C2=A0 =C2=A0Menzies, Alfred; van Oorscot, Paul C.; Vanstone, SCOTT (19= 97).
>=C2=A0 =C2=A0Handbook of Applied Cryptography. CRC Pres. ISBN 978-0-849= 3-8523-0.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0In cryptography, forward secrecy (FS), also = known as perfect
>=C2=A0 =C2=A0 =C2=A0 =C2=A0forward secrecy (PFS), is a feature of speci= fic key agreement
>=C2=A0 =C2=A0 =C2=A0 =C2=A0protocols that gives assurances that session= keys will not be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0compromised even if the private key of the s= erver is compromised.
>
> There is also https://www.perfectforwardsecrecy.com/ which has a paragraph
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Forward Secrecy has been used as a synonym f= or Perfect Forward
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Secrecy but there is a subtle difference bet= ween the two. Perfect
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Forward Secrecy has the additional property = that an agreed key
>=C2=A0 =C2=A0 =C2=A0 =C2=A0will not be compromised even if agreed keys = derived from the same
>=C2=A0 =C2=A0 =C2=A0 =C2=A0long-term keying material in a subsequent ru= n are compromised.
>
> along with more justification of differences.

Are there examples in Internet protocols of FS key agreement protocols
that aren't also PFS?=C2=A0 I'm not denying that it's possible = to construct an
FS-but-not-PFS key agreement protocols, but I'm wondering whether we need a name for those when we wouldn't want to have any of them.

I've honestly never seen this particular = distinction of FS vs. PFS drawn and I'm not quite sure it's that us= eful.

Consider the case of a typical SIGMA-bas= ed AKE like TLS. The handshake protocol typically spits out one piece of sh= ared entropy (e.g., the TLS 1.2 master secret) which is then key expanded i= nto multiple working (traffic) keys. Assuming a strong KDF, then generally = working key A cannot be used to derive working key B. However, the MS can b= e used to derive A or B. So is this PFS or just FS? Depends on where you dr= aw the line for "agreed key", right?

To = make things more complicated, when you have a protocol that offers resumpti= on (as with TLS) you have to be able to talk about the FS properties of res= umed data, which may be different from those of the rest of the data. As a = concrete example:

- In TLS 1.2, you need to store = the MS as long as you want resumption, which means that compromise of the s= ession database at time T2 also compromises stored sessions from time T1 &l= t; T.
- In TLS 1.3, the resumption master secret is different fro= m the MS, so compromise at T2 doesn't compromise T1 if you use a sessio= n database and delete promptly. However if you use session tickets, then th= e STK threatens PFS. So in this case, it's not even a property of the A= KE.

=


-Ekr

--000000000000a75f0d05a1243c71-- From nobody Wed Mar 18 12:31:20 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9323E3A1AA9 for ; Wed, 18 Mar 2020 12:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, 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=cryptonector.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 QXOowav2h4Hq for ; Wed, 18 Mar 2020 12:31:17 -0700 (PDT) Received: from black.elm.relay.mailchannels.net (black.elm.relay.mailchannels.net [23.83.212.19]) (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 07CD63A1AA4 for ; Wed, 18 Mar 2020 12:31:16 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id BD14D21EBC; Wed, 18 Mar 2020 19:31:15 +0000 (UTC) Received: from pdx1-sub0-mail-a58.g.dreamhost.com (100-96-215-21.trex.outbound.svc.cluster.local [100.96.215.21]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id BFEC821E45; Wed, 18 Mar 2020 19:31:14 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a58.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Wed, 18 Mar 2020 19:31:15 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Scare-Invention: 387676ad2e33cffe_1584559875426_2443504614 X-MC-Loop-Signature: 1584559875425:1220657887 X-MC-Ingress-Time: 1584559875425 Received: from pdx1-sub0-mail-a58.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a58.g.dreamhost.com (Postfix) with ESMTP id 2A62880524; Wed, 18 Mar 2020 12:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=e8ckrBCGYQ/4u2 5FA9yz2Gi/tEI=; b=ds2Xa1gNqwwhVHhYS1q5cSRfgwFcxALcPOHm2FKkHCvQH7 hgp3fqt61rXZ73UqB0E0mu3E/RBcV1gaqSqpba4gIdbJo5bUuxUe9jfyz+16jsdl TonG4zGsIOB35gZchawkNbMTAXygCtpw7BvlhjTwxX1rEMo6h1/W5PBF2IC2k= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a58.g.dreamhost.com (Postfix) with ESMTPSA id 3F077802A7; Wed, 18 Mar 2020 12:31:07 -0700 (PDT) Date: Wed, 18 Mar 2020 14:31:04 -0500 X-DH-BACKEND: pdx1-sub0-mail-a58 From: Nico Williams To: Eric Rescorla Cc: "Mark D. Baushke" , saag@ietf.org Message-ID: <20200318193103.GK18021@localhost> References: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> <6b73afd0-6eda-4533-a499-166934702f6e@www.fastmail.com> <3517.1584548794@eng-mail01.juniper.net> <20200318164718.GJ18021@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrudefjedguddukecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucffohhmrghinhepphgvrhhfvggtthhfohhrfigrrhgushgvtghrvggthidrtghomhdpihgvthhfrdhorhhgnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Archived-At: Subject: Re: [saag] Perfect Forward Secrecy vs Forward Secrecy X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 19:31:19 -0000 On Wed, Mar 18, 2020 at 10:17:35AM -0700, Eric Rescorla wrote: > On Wed, Mar 18, 2020 at 9:47 AM Nico Williams wrote: > > On Wed, Mar 18, 2020 at 09:26:34AM -0700, Mark D. Baushke wrote: > > > There is also https://www.perfectforwardsecrecy.com/ which has a > > > paragraph > > > > > > Forward Secrecy has been used as a synonym for Perfect Forward > > > Secrecy but there is a subtle difference between the two. Perfect > > > Forward Secrecy has the additional property that an agreed key > > > will not be compromised even if agreed keys derived from the same > > > long-term keying material in a subsequent run are compromised. > > > > Are there examples in Internet protocols of FS key agreement protocols > > that aren't also PFS? I'm not denying that it's possible to construct an > > FS-but-not-PFS key agreement protocols, but I'm wondering whether we > > need a name for those when we wouldn't want to have any of them. > > I've honestly never seen this particular distinction of FS vs. PFS drawn > and I'm not quite sure it's that useful. +1. Calling this just FS and not PFS is fine with me, even if fear of misunderstanding "perfect" strikes anyone as silly. > Consider the case of a typical SIGMA-based AKE like TLS. The handshake > protocol typically spits out one piece of shared entropy (e.g., the TLS 1.2 > master secret) which is then key expanded into multiple working (traffic) > keys. Assuming a strong KDF, then generally working key A cannot be used to > derive working key B. However, the MS can be used to derive A or B. So is > this PFS or just FS? Depends on where you draw the line for "agreed key", > right? +1 > ISTM that using "perfect" or not doesn't convey enough info and we should > instead talk about protocols being forward secure with respect to certain > attacks (as is the case in MLS). See for instance: > https://tools.ietf.org/rfcmarkup?doc=8446#section-8.1 +1. From nobody Wed Mar 18 13:26:33 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006CB3A1B95 for ; Wed, 18 Mar 2020 13:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=blackberry.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 yAAupxepHy6z for ; Wed, 18 Mar 2020 13:26:28 -0700 (PDT) Received: from smtp-pg10.blackberry.com (smtp-pg10.blackberry.com [68.171.242.226]) (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 771493A1B9B for ; Wed, 18 Mar 2020 13:26:27 -0700 (PDT) Received: from pps.filterd (mhs400ykf.rim.net [127.0.0.1]) by mhs400ykf.rim.net (8.16.0.27/8.16.0.27) with SMTP id 02IK6vPR179737; Wed, 18 Mar 2020 16:26:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blackberry.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp19; bh=TJEY/cGPbw+igA5N9dmBKDIdtwfAtV3U2Kg9KCx2sfk=; b=oFeGhWYnZWV8Aa7b5pR8B74KQp+b827vzeP/GQVWUqrt2by0FuVBBCg3bWA09ZVekAwe WGvzQt9aeD1df8Gtl6UTzgIsIPtWQSi1+tgU2zlmybrvm4K5RuvfbpPeOKfoFexcT8TN VYWPjLl9YyYGSiwSETXvzI3K9bAdwgcvrpXCVY2Ro/I+MP/nQ1eTaRwPd+S2K1jox4zQ jhjySYP8YdKWYdprY3YVL9cQSf76CXAJMzRp79AhSQGxn1f4Ae0W7nQ4WOOPJjmwImFT H/2q25LHeHu4PueFZPffOC5Vc1ZqJg3zFnAI87nIOgD+om+3Rr0QRm/DqehzvtSlV+3u ow== Received: from xch211cnc.rim.net (xch211cnc.rim.net [10.3.27.116]) by mhs400ykf.rim.net with ESMTP id 2yuraf0b6g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 18 Mar 2020 16:26:20 -0400 Received: from XCH210YKF.rim.net (10.2.27.110) by XCH211CNC.rim.net (10.3.27.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 18 Mar 2020 16:26:19 -0400 Received: from XCH210YKF.rim.net ([fe80::81ca:ad34:fc3:5ce8]) by XCH210YKF.rim.net ([fe80::81ca:ad34:fc3:5ce8%5]) with mapi id 15.01.1913.007; Wed, 18 Mar 2020 16:26:19 -0400 From: Dan Brown To: Dan Brown , "Salz, Rich" , Robert Moskowitz , "saag@ietf.org" Thread-Topic: [saag] Perfect Forward Secrecy vs Forward Secrecy Thread-Index: AQHV/TKnv/elDdMNE0+7rke4G0Sq8ahOsTMAgAABcQCAAAHUAP//zF7wgABGPoA= Date: Wed, 18 Mar 2020 20:26:19 +0000 Message-ID: <00475ac5178a456eb352e397ca9b98b1@blackberry.com> References: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> <89121466-d091-5f22-a053-a2a618946908@htt-consult.com> <18624c8526f94f8892d80bb756e543c6@blackberry.com> In-Reply-To: <18624c8526f94f8892d80bb756e543c6@blackberry.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [100.64.97.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.645 definitions=2020-03-18_07:2020-03-18, 2020-03-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=620 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2003180088 Archived-At: Subject: Re: [saag] Perfect Forward Secrecy vs Forward Secrecy X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 20:26:31 -0000 > -----Original Message----- > From: saag On Behalf Of Dan Brown > does not use the term perfect, which I think is a good idea. I prefer "forward secrecy" (or forward security), so no "perfect", please. = [To clarify my ambiguous grammar above with a clause appended to negation,= oops.]=20 The bike-shed color "perfect" should be avoided because it is too garish, m= etaphorically. The term "perfect" is unclear and inaccurate, no matter what= formal definition is attached to it.=20 The term-of-the-art justifications for perpetuating "perfect" are imperfect= , based on my limited understanding of the art, but also based on the gener= al principle of reform, evolution, and improvement, ever towards a more per= fect world.=20=20 ---------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From nobody Sun Mar 22 18:19:54 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B33D3A094B for ; Sun, 22 Mar 2020 18:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 Y_rXv_RcT5xF for ; Sun, 22 Mar 2020 18:19:50 -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 CC6063A094C for ; Sun, 22 Mar 2020 18:19:49 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 02N1Je9W009165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 22 Mar 2020 21:19:42 -0400 Date: Sun, 22 Mar 2020 18:19:40 -0700 From: Benjamin Kaduk To: saag@ietf.org Message-ID: <20200323011940.GI50174@kduck.mit.edu> References: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [saag] Perfect Forward Secrecy vs Forward Secrecy X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 01:19:52 -0000 On Wed, Mar 18, 2020 at 09:38:07AM -0700, Jon Callas wrote: > > We don't do "perfect" security in our fundamentals, because, as the unnamed AD said, it's hard to achieve. For what little it's worth, the AD doesn't have to be unnamed; I'm happy to own up to making the request of Bob. I just haven't gotten fully caught up on mail yet. -Ben From nobody Mon Mar 23 10:58:14 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C243A0E1E for ; Mon, 23 Mar 2020 10:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 LcpSsCCLavv9 for ; Mon, 23 Mar 2020 10:57:45 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 B22A93A0E33 for ; Mon, 23 Mar 2020 10:57:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 5398F62145; Mon, 23 Mar 2020 13:57:44 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YP-SdXBPam6I; Mon, 23 Mar 2020 13:57:39 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 82E5D6212E; Mon, 23 Mar 2020 13:57:39 -0400 (EDT) To: Benjamin Kaduk , saag@ietf.org References: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> <20200323011940.GI50174@kduck.mit.edu> From: Robert Moskowitz Message-ID: <117849db-3b7a-d0ec-ccf7-7315e935a13b@htt-consult.com> Date: Mon, 23 Mar 2020 13:57:26 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200323011940.GI50174@kduck.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [saag] Perfect Forward Secrecy vs Forward Secrecy X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 17:58:13 -0000 On 3/22/20 9:19 PM, Benjamin Kaduk wrote: > On Wed, Mar 18, 2020 at 09:38:07AM -0700, Jon Callas wrote: >> We don't do "perfect" security in our fundamentals, because, as the unnamed AD said, it's hard to achieve. > For what little it's worth, the AD doesn't have to be unnamed; I'm happy to > own up to making the request of Bob. I just haven't gotten fully caught up > on mail yet. And draft 17 reflects this view of Forward Secrecy. Thanks, Ben. From nobody Wed Mar 25 14:03:04 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1073A0C7A; Wed, 25 Mar 2020 14:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.615 X-Spam-Level: * X-Spam-Status: No, score=1.615 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, FREEMAIL_FROM=0.001, LOTS_OF_MONEY=0.001, MALFORMED_FREEMAIL=1.713, PDS_TONAME_EQ_TOLOCAL_HDRS_LCASE=1.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 SAQHWxtH71Mf; Wed, 25 Mar 2020 14:02:55 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 E8D703A0A46; Wed, 25 Mar 2020 14:02:54 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id s1so5174137wrv.5; Wed, 25 Mar 2020 14:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version:content-transfer-encoding; bh=DPCHLtW+CfURCB9p2wBHDKqgP/LsyMNfj1m2gRODc6o=; b=qsIolk53SWUW0rHozJ75whiwaMsqbXR81lb1qE9tCw8fkuqRqeVz6gefA9hczpiDgP 6zyPET1IpIlzyqr6IkDPhziV0M0aMrYQTHOvXtm/PI0QqckclzUfVu2Ohvbu/DfIDVvX u7dOwckp95+kfZwCPgprcClLR8jF+/s1YCZRauUZohbBpBzwDDdVYXlRyAOgQVQypXvn TxeL2q9xnkxHB5D2OZAGsdUMnCDANJycthkvw0PxvQ1KZQyOn3Nn9TQJjnzjPUKCQDY5 BSTVn5X2pC6LG+IkI/m5AgDJ3Ir0uX2PMqaxqxE/OempukLmnzrk26W3CeG+fu7BvE7m Nd4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version:content-transfer-encoding; bh=DPCHLtW+CfURCB9p2wBHDKqgP/LsyMNfj1m2gRODc6o=; b=f+mP4ulSNvc4Zc5Pm9+eIw+mXsdKRAutDO02Zh315xHbm+6yHl0lelYEub0NvCHceZ UNLoG5TioVi7JX0fidW9OBsubhRQ8fP36RBHMga3Klc8nDtx5wa3n5ErmxGotv1DnhEr NyfO6ArDz6wa412q1iN/Ad39KIFC8PzmzddB1o2UiBOwToiCb+Tk3TMJ5eip13HpfciZ lkM2XDPEczJwW8LN64I4IX8x0KXI3kIaKGLzVJipArbac4c0nJ7C8mEQUjbFBl7b1v1v YtHoFfgCGZHI8tEB4bqOUA6eGwvd8+A6HU8h7U2JoudNfP5MNc1gNLqjdhoQAuT2Jo7d 5+Ww== X-Gm-Message-State: ANhLgQ0FKhz7iSLFXPnqfeTBAc0AwZmSOgOrAnFRJ3qJBz/rYdNZ2xk/ iF5agRrUdazFSHkvMC+b291H6lJp X-Google-Smtp-Source: ADFU+vsifAVjEVhS9TEnzshmBUIUWfOVhdaZSjBD/ZJGI506xBZqG/FeZajUs7hM3r6G8i/mvH0ApA== X-Received: by 2002:a5d:4085:: with SMTP id o5mr5178720wrp.327.1585170171666; Wed, 25 Mar 2020 14:02:51 -0700 (PDT) Received: from [10.0.0.157] (bzq-79-178-60-210.red.bezeqint.net. [79.178.60.210]) by smtp.gmail.com with ESMTPSA id n124sm360999wma.11.2020.03.25.14.02.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2020 14:02:50 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.35.20030802 Date: Wed, 25 Mar 2020 23:02:48 +0200 From: Yaron Sheffer To: ietf , "saag@ietf.org" , "cfrg@irtf.org" CC: "Rohloff, Kurt" , Kim Laine , Dave Thaler , Message-ID: <94CED3F7-BEBF-4E1B-A6B6-F464742BFAD5@gmail.com> Thread-Topic: Homomorphic Encryption Standardization =?UTF-8?B?4oCT?= Side Meeting Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [saag] =?utf-8?q?Homomorphic_Encryption_Standardization_?= =?utf-8?q?=E2=80=93_Side_Meeting?= X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 21:03:01 -0000 Apologies for cross-posting. Dear IETFers, We would like to introduce the work of the Homomorphic Encryption Standardization consortium [1] to the IETF and IRTF community, and solicit feedback about the next steps to standardize this encryption technology. This was originally intended as an IETF-107 side meeting, instead we will hold it as a virtual meeting the week after IETF-107. Date/time: Tue March 31, 10:00-11:00 PST, 13:00-14:00 EST, 17:00-18:00 UTC, 20:00-21:00 IL. Meeting link: https://intuit.zoom.us/j/555682817 We do not have an IETF-hosted mailing list yet, for discussion pre- and post-meeting, please join the homomorphicencryption.org Standards mailing list at [2]. Thanks, Kurt, Kim and Yaron [1] https://homomorphicencryption.org/ [2] https://groups.google.com/a/homomorphicencryption.org/forum/#!forum/standards Additional Zoom information: One tap mobile +13017158592,,555682817# US +13126266799,,555682817# US (Chicago) Dial-In Only +1 301 715 8592 US +1 312 626 6799 US (Chicago) +1 346 248 7799 US (Houston) +1 646 558 8656 US (New York) +1 669 900 6833 US (San Jose) +1 253 215 8782 US 888 475 4499 US Toll-free 877 853 5257 US Toll-free Meeting ID: 555 682 817 International Numbers: https://intuit.zoom.us/u/aezA7EnRm From nobody Thu Mar 26 09:32:12 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599E63A03FC for ; Thu, 26 Mar 2020 09:32:09 -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, SPF_HELO_NONE=0.001, 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=wesleyan.edu 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 nifb0qVfrYkC for ; Thu, 26 Mar 2020 09:32:07 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 3B7AD3A00D9 for ; Thu, 26 Mar 2020 09:32:07 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id o3so1107670ioh.2 for ; Thu, 26 Mar 2020 09:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wesleyan.edu; s=wesgmail; h=mime-version:from:date:message-id:subject:to; bh=uJa53zh2xqxQ/UGlzAXtfFwIg2xZJUvb6T0z28xGf1I=; b=ornjwTtTRYS/EbXUPKV6n0sKdG+7Ku5BInn0uR1zZZLPVJiZuN3twDMytPGJXlJrN5 suqv/kStA0LPEnhULZvGEBIqw22IKNOeUJZggRYJFGw7EVpvbgsHK2ADC6c/vHluztL3 NeVnYn30d8FHFf3OmtV0nDCi4AJZi7d1R61/I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uJa53zh2xqxQ/UGlzAXtfFwIg2xZJUvb6T0z28xGf1I=; b=Liut2CQGDEaAsYZiIEckvSYiBR7VBKgq85bL7qeUfxDy6vJb8WNuf5I1z+H6vWh8qY +sUyviRjfmPCjWFPQRU0RXoeUhhBPTkYmXjRmbolYCWbZEXR5WBvKckpX/YTQPFZaKwD liGfBclED4kH7t9dN9MAFhUTIuF1GTfUe8msPvbPvRCwo0yCm88rVcxZ6HuHGB/zNJt7 1dpLahpyT5c/L/cF5CBQW8XfmzcjGXNPyX+Gk7vha9N/Mdz3ACI2dlIyYojTfLiJOn8n 4JjgT4qv9SqMa2y4JsJ2jQwotnnRi0+Zk0aD2BgxDy4FebWOpUxmd2zKSnAFKX+TmU5q GkRg== X-Gm-Message-State: ANhLgQ2qV0qmkZBnwSJ6jI7361CiPI20GvFRJjRnaPm3jw4DfxlQc875 XaBhANiYFmr9kAyqzdgVMXRHoE0bAJeU2h1n0UEDUcSuWn0= X-Google-Smtp-Source: ADFU+vuXzrgQ1uDQSmyQG75TrXUpU4eLJwt0ux3zPy6eaBhvm8JmzZzdUBm/AM75HvwfSWSbfjwLoAKcb9tW5MQC21Y= X-Received: by 2002:a02:cbb6:: with SMTP id v22mr8069095jap.78.1585240325978; Thu, 26 Mar 2020 09:32:05 -0700 (PDT) MIME-Version: 1.0 From: Sebastian Zimmeck Date: Thu, 26 Mar 2020 12:31:55 -0400 Message-ID: To: saag@ietf.org Content-Type: multipart/alternative; boundary="000000000000838bf205a1c486d7" Archived-At: Subject: [saag] CCPA Do-Not-Sell X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 16:32:10 -0000 --000000000000838bf205a1c486d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable At the beginning of this year the California Consumer Privacy Act (CCPA) became effective. In addition to the rights of data access and deletion, this new privacy law gives consumers the right to opt out from the sale of personal information. A "sale" is understood broadly and likely covers, for example, a website or app disclosing location data or device identifiers to an ad network for purposes of monetization. Now, the most recent regulation= s to the CCPA published by the California Attorney General specify that automatic signals communicating a user's decision to opt out must be respected. Here is the relevant language: "If a business collects personal information from consumers online, the business shall treat user-enabled global privacy controls, such as a browser plugin or privacy setting, device setting, or other mechanism, that communicate or signal the consumer=E2=80=99s choice to opt-out of the sale = of their personal information as a valid request ... ." I am interested in setting up a working group on such device controls. The Do-Not-Sell signal could be similar to a Do-Not-Track (DNT) signal. However, the difference is that recipients of the DNT signal were not required to comply with the signal. Rather, they only needed to *say* wheth= er they would comply; per the California Online Privacy Protection Act (CalOPPA). Also, the CCPA may have substantial impact beyond California as some companies, e.g., Microsoft, already made clear that they would apply the CCPA to all consumers in the US. It would be great to get a discussion started ... Best regards, Sebastian _______________________________________________ Check out PrivacyFlash Pro Developed at the privacy-tech-lab , Wesleyan University --000000000000838bf205a1c486d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At the beginning of this year the California Consumer= Privacy Act (CCPA) became effective. In addition to the rights of data acc= ess and deletion, this new privacy law gives consumers the right to opt=C2= =A0out from the sale of personal information. A "sale" is underst= ood broadly and likely covers, for example, a website or app disclosing loc= ation data or device identifiers to an ad network for purposes of monetizat= ion. Now, the most recent=C2=A0regulations to the CCPA=C2=A0published by the California Attor= ney General specify that automatic signals communicating a user's decis= ion to opt out must be respected. Here is the relevant language:
=
"If a business collects personal information from consu= mers online, the business shall treat user-enabled global privacy controls,= such as a browser plugin or privacy setting, device setting, or other mech= anism, that communicate or signal the consumer=E2=80=99s choice to opt-out = of the sale of their personal information as a valid request ... ."=C2= =A0

I am interested in setting up a working group = on such device controls. The Do-Not-Sell signal could be similar to a Do-No= t-Track (DNT) signal. However, the difference is that recipients of the DNT= signal were not required to comply with the signal. Rather, they only need= ed to=C2=A0say=C2=A0whether they would comply; per the California On= line Privacy Protection Act (CalOPPA).

Also, the C= CPA may have substantial impact beyond California as some companies, e.g., = Microsoft, already made clear that they would apply the CCPA to all consume= rs in the US.

It would be great to get a discussio= n started ...
<= div dir=3D"ltr">

Best regards,
Sebastian

______________________= _________________________
Check out=C2=A0PrivacyFlash Pro=
Developed at the=C2=A0privacy-tech-lab, Wesleyan University
<= /div>
--000000000000838bf205a1c486d7-- From nobody Thu Mar 26 11:23:09 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6DC3A0BD6; Thu, 26 Mar 2020 11:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 g9gvS_ui0sWG; Thu, 26 Mar 2020 11:23:01 -0700 (PDT) Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) (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 758F53A0A9F; Thu, 26 Mar 2020 11:23:01 -0700 (PDT) Received: by mail-oi1-f175.google.com with SMTP id y71so6394631oia.7; Thu, 26 Mar 2020 11:23:01 -0700 (PDT) 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=V9QDs3Gv/oAqCxdVX6yiDHW9PxuMPrYEodszWvwLMw8=; b=hgN/dLxO2kwUW8xOQvQmtH5VFfOn9ZW8ZYGI/qbqCzzx8zbZNPAXDL/1hNwpEG+yiI 2KRt5a9t40UQsWFKUNMZpv/nP7wyYiLObi1VywLzJskvF4lckZZ3Hjo+y8SZ8nKn0fCw v/VN3fLMTY/juvwluOUEoH9m5hZqTZBRmdc/VcWHMaKqotriDHoiOSY1ZuR8gMNU+NhD fbwOUgccPdQQTKTEU7xAvmJVyvUMMxEbmzx6/cY6rdEOUVtQZ6CWm6Vu4iz6/GP5S8dW TQirBFwfrJzbBym2ZpYDI9NlC9lkSaL2NwPb2gYZUsp/9FLzfTQz9YuMV0o8D8YTDtoI ptmw== X-Gm-Message-State: ANhLgQ0sI37d4qPG2VlDR58NAWRmGU6bg6fFNDpXmQ0jQIukGvFaxozG LkZLMh5N8Qn2JMuuLXZXUyQIB6aMpgRzn+qFrD4= X-Google-Smtp-Source: ADFU+vv+obet1AV527UYgEEQaWbdXj9izOhAGn7u7kjr2DpJa8Gbs42DPwTK3gF76c2xlqSqjy51KSpg4wcqrFW2/iA= X-Received: by 2002:aca:cd58:: with SMTP id d85mr1156194oig.173.1585246980470; Thu, 26 Mar 2020 11:23:00 -0700 (PDT) MIME-Version: 1.0 References: <94CED3F7-BEBF-4E1B-A6B6-F464742BFAD5@gmail.com> In-Reply-To: <94CED3F7-BEBF-4E1B-A6B6-F464742BFAD5@gmail.com> From: Phillip Hallam-Baker Date: Thu, 26 Mar 2020 14:22:49 -0400 Message-ID: To: Yaron Sheffer Cc: ietf , "saag@ietf.org" , "cfrg@irtf.org" , Kim Laine , Dave Thaler , standards@homomorphicencryption.org Content-Type: multipart/alternative; boundary="00000000000026fb8d05a1c61328" Archived-At: Subject: Re: [saag] =?utf-8?q?=5BCfrg=5D_Homomorphic_Encryption_Standardizati?= =?utf-8?q?on_=E2=80=93_Side_Meeting?= X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 18:23:03 -0000 --00000000000026fb8d05a1c61328 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 25, 2020 at 5:03 PM Yaron Sheffer wrote: > Apologies for cross-posting. > > Dear IETFers, > > We would like to introduce the work of the Homomorphic Encryption > Standardization consortium [1] to the IETF and IRTF community, and solicit > feedback about the next steps to standardize this encryption technology. > This was originally intended as an IETF-107 side meeting, instead we will > hold it as a virtual meeting the week after IETF-107. > > Date/time: Tue March 31, 10:00-11:00 PST, 13:00-14:00 EST, 17:00-18:00 > UTC, 20:00-21:00 IL. > I would like to see this brought into IRTF as soon as possible either as part of CFRG or as a separate effort. Right now the canon of commercial cryptography uses only the primitives developed up to 1990 (hash chains). I am currently trying to persuade people to make use of threshold cryptography techniques that were developed in the mid 90s. We need to get out of the habit of waiting 25 years for new cryptographic primitives to mature before we start looking at them. We should stop asking 'does anyone need this' and instead ask 'is this useful'. The other reason for bringing it into IRTF is that we really do need a clear IPR regime or else things can get ugly and efforts can stall. --00000000000026fb8d05a1c61328 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Mar 25, 2020 at 5:03 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Apologies for cross-posting.

Dear IETFers,

We would like to introduce the work of the Homomorphic Encryption Standardi= zation consortium [1] to the IETF and IRTF community, and solicit feedback = about the next steps to standardize this encryption technology. This was or= iginally intended as an IETF-107 side meeting, instead we will hold it as a= virtual meeting the week after IETF-107.

Date/time: Tue March 31, 10:00-11:00 PST, 13:00-14:00 EST, 17:00-18:00 UTC,= 20:00-21:00 IL.

I would like to see this brought into IRTF= as soon as possible either as part of CFRG or as a separate effort.
<= div class=3D"gmail_default" style=3D"font-size:small">
Right now the canon of commerc= ial cryptography uses only the primitives developed up to 1990 (hash chains= ). I am currently trying to persuade people to make use of threshold crypto= graphy techniques that were developed in the mid 90s. We need to get out of= the habit of waiting 25 years for new cryptographic primitives to mature b= efore we start looking at them.

We should stop asking 'does anyone need this' and instead as= k 'is this useful'.

The other reason for bringing it into IRTF is that we really do need a c= lear IPR regime or else things can get ugly and efforts can stall.
=C2=A0
--00000000000026fb8d05a1c61328-- From nobody Thu Mar 26 11:39:19 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AE03A0DBC; Thu, 26 Mar 2020 11:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 4mMnUDk3-H8q; Thu, 26 Mar 2020 11:38:53 -0700 (PDT) Received: from camel.birch.relay.mailchannels.net (camel.birch.relay.mailchannels.net [23.83.209.29]) (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 129C33A0E2A; Thu, 26 Mar 2020 11:38:52 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 58C34120EBA; Thu, 26 Mar 2020 18:38:52 +0000 (UTC) Received: from pdx1-sub0-mail-a2.g.dreamhost.com (100-96-54-12.trex.outbound.svc.cluster.local [100.96.54.12]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 95141120F74; Thu, 26 Mar 2020 18:38:51 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a2.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Thu, 26 Mar 2020 18:38:52 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Gusty-Glossy: 7c0f658c2c1d8e20_1585247931946_817719937 X-MC-Loop-Signature: 1585247931946:1489903923 X-MC-Ingress-Time: 1585247931945 Received: from pdx1-sub0-mail-a2.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a2.g.dreamhost.com (Postfix) with ESMTP id 1C1447F4F1; Thu, 26 Mar 2020 11:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=TX0If+xr+AlHoX vaYDXwPI12NIM=; b=KMeFtvPLWzMpZzrcHGrUUL5zoQUQNFndJ1jrgpP1vrunLK DSjN4qsYC69GV4lRW6zCmUS2aoMl7GDfvOToo5nqqZ5XzrzxJLWfpkkPbYufEORx 3Q2ShrqNn83ylQhYEoxCOdUUmjhmd0u2dky+liVJ/+Zb9a7PG17A1MRFu2rko= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a2.g.dreamhost.com (Postfix) with ESMTPSA id 96AE07F4EC; Thu, 26 Mar 2020 11:38:46 -0700 (PDT) Date: Thu, 26 Mar 2020 13:38:43 -0500 X-DH-BACKEND: pdx1-sub0-mail-a2 From: Nico Williams To: Phillip Hallam-Baker Cc: Yaron Sheffer , ietf , standards@homomorphicencryption.org, "cfrg@irtf.org" , "saag@ietf.org" , Kim Laine Message-ID: <20200326183842.GN18021@localhost> References: <94CED3F7-BEBF-4E1B-A6B6-F464742BFAD5@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrudehjedgheduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [saag] =?utf-8?q?=5BCfrg=5D_Homomorphic_Encryption_Standardizati?= =?utf-8?q?on_=E2=80=93_Side_Meeting?= X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 18:39:12 -0000 On Thu, Mar 26, 2020 at 02:22:49PM -0400, Phillip Hallam-Baker wrote: > I would like to see this brought into IRTF as soon as possible either as > part of CFRG or as a separate effort. > > Right now the canon of commercial cryptography uses only the primitives > developed up to 1990 (hash chains). I am currently trying to persuade > people to make use of threshold cryptography techniques that were developed > in the mid 90s. We need to get out of the habit of waiting 25 years for new > cryptographic primitives to mature before we start looking at them. > > We should stop asking 'does anyone need this' and instead ask 'is this > useful'. +1. > The other reason for bringing it into IRTF is that we really do need a > clear IPR regime or else things can get ugly and efforts can stall. I hope by now everyone understands that patent IPR on crypto == 20 year kiss of death. That explains a great deal of our collective habit of waiting 20+ years to make use of new primitives -- it certainly does for PAKEs, for example. Of course, for some that might be a feature. Nico -- From nobody Thu Mar 26 11:50:12 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD81A3A07E8; Thu, 26 Mar 2020 11:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 mOeORZHhoAhr; Thu, 26 Mar 2020 11:49:52 -0700 (PDT) Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) (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 4D18E3A079D; Thu, 26 Mar 2020 11:49:52 -0700 (PDT) Received: by mail-ot1-f54.google.com with SMTP id 111so7020445oth.13; Thu, 26 Mar 2020 11:49:52 -0700 (PDT) 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=yDPPK5q67u7VdhD1LFbt8/97H59rbj3xFi+uWdBRgvI=; b=ttaqWWVs16y52b7petl1vsn86d59IdCmI9Ehcgr1UwQskCEvnIvBy5Fj7yieWUfG6r 1TmZma16EjA9vqGNRc/wY9Scf4/GVqp0MMNilcjptVR7YL5JFA3e0Drtw5Dz3uOAKYeO 8JhJ12y/ZUVbIiA5GI1K+kBoZjSoZ1bWSD9ctw1YW7qmtmruJRFg7cEK5D10MaWUce4y tly4cwu7gowrZj3NVMEwgGDaaMm5XJhefJQsPfoqTTYzLnOHTcAECjVS6uhpbOBrNI/k xXgxyImmF2RFFBRsT/uCGVRX8y+wVCkRBrLlF7MJNAIHcGieCxIbGu+slIIC79x2zWbn t/7w== X-Gm-Message-State: ANhLgQ3YTcEn9G0NFWs3VC+XAr8jIU+UsmhVkWArSNx/VE1KQpfJyGXC cfG6yae5HbLPLtvw54LOl9Le78Nk3HOZRYQhsok= X-Google-Smtp-Source: ADFU+vvycpP9Gm/LAN0KjS0NDZcF4+1AduXVe50lUh+BRNg4oFFPLwKteKzGB4r8FwDDkADMbte7gAfjsYAQWK8lwJU= X-Received: by 2002:a9d:62c2:: with SMTP id z2mr967882otk.155.1585248591398; Thu, 26 Mar 2020 11:49:51 -0700 (PDT) MIME-Version: 1.0 References: <94CED3F7-BEBF-4E1B-A6B6-F464742BFAD5@gmail.com> <20200326183842.GN18021@localhost> In-Reply-To: <20200326183842.GN18021@localhost> From: Phillip Hallam-Baker Date: Thu, 26 Mar 2020 14:49:40 -0400 Message-ID: To: Nico Williams Cc: Yaron Sheffer , ietf , standards@homomorphicencryption.org, "cfrg@irtf.org" , "saag@ietf.org" , Kim Laine Content-Type: multipart/alternative; boundary="0000000000002bce6705a1c67371" Archived-At: Subject: Re: [saag] =?utf-8?q?=5BCfrg=5D_Homomorphic_Encryption_Standardizati?= =?utf-8?q?on_=E2=80=93_Side_Meeting?= X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 18:49:54 -0000 --0000000000002bce6705a1c67371 Content-Type: text/plain; charset="UTF-8" On Thu, Mar 26, 2020 at 2:38 PM Nico Williams wrote: > On Thu, Mar 26, 2020 at 02:22:49PM -0400, Phillip Hallam-Baker wrote: > > The other reason for bringing it into IRTF is that we really do need a > > clear IPR regime or else things can get ugly and efforts can stall. > > I hope by now everyone understands that patent IPR on crypto == 20 year > kiss of death. That explains a great deal of our collective habit of > waiting 20+ years to make use of new primitives -- it certainly does for > PAKEs, for example. Of course, for some that might be a feature. > +1 I follow the expiry of patents pretty closely. The Mesh uses crypto that was patent encumbered until very recently. A feature I have not yet added to the Mesh messaging layer but plan to add is Micali's simultaneous contracts. --0000000000002bce6705a1c67371 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Mar 26, 2020 at 2:38 PM Nico Williams <<= a href=3D"mailto:nico@cryptonector.com">nico@cryptonector.com> wrote= :
On Thu, Mar 26= , 2020 at 02:22:49PM -0400, Phillip Hallam-Baker wrote:
=C2=A0
> The other reason for bringing it i= nto IRTF is that we really do need a
> clear IPR regime or else things can get ugly and efforts can stall.
I hope by now everyone understands that patent IPR on crypto =3D=3D 20 year=
kiss of death.=C2=A0 That explains a great deal of our collective habit of<= br> waiting 20+ years to make use of new primitives -- it certainly does for PAKEs, for example.=C2=A0 Of course, for some that might be a feature.
<= /blockquote>

+1

<= /div>
I follow the ex= piry of patents pretty closely. The Mesh uses crypto that was patent encumb= ered until very recently.

A feature I have not yet added to the Mesh messaging layer but plan to add= is Micali's simultaneous contracts.
--0000000000002bce6705a1c67371-- From nobody Thu Mar 26 12:39:05 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B093A0BFE; Thu, 26 Mar 2020 12:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.274, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 lqB8Dqbgwjiy; Thu, 26 Mar 2020 12:38:45 -0700 (PDT) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) (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 99BA63A0BDE; Thu, 26 Mar 2020 12:38:44 -0700 (PDT) Received: from LLE2K16-MBX04.mitll.ad.local (LLE2K16-MBX04.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTPS id 02QIc3AK039771; Thu, 26 Mar 2020 14:38:03 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Phillip Hallam-Baker , Yaron Sheffer CC: ietf , "standards@homomorphicencryption.org" , "cfrg@irtf.org" , "saag@ietf.org" Thread-Topic: =?utf-8?B?W0NmcmddIEhvbW9tb3JwaGljIEVuY3J5cHRpb24gU3RhbmRhcmRpemF0aW9u?= =?utf-8?B?IOKAkyBTaWRlIE1lZXRpbmc=?= Thread-Index: AQHWAukNMMYzc/rEkk2B5/ud5OZatahbdFeA///BMwA= Date: Thu, 26 Mar 2020 18:38:02 +0000 Message-ID: <32DA1AF1-FC2D-416F-8D3A-02FA18EA251B@ll.mit.edu> References: <94CED3F7-BEBF-4E1B-A6B6-F464742BFAD5@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 x-originating-ip: [172.25.1.90] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3668078282_1073986792" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.645 definitions=2020-03-26_10:2020-03-26, 2020-03-26 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=800 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2003260138 Archived-At: Subject: Re: [saag] =?utf-8?q?=5BCfrg=5D_Homomorphic_Encryption_Standardizati?= =?utf-8?q?on_=E2=80=93_Side_Meeting?= X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 19:38:47 -0000 --B_3668078282_1073986792 Content-type: multipart/alternative; boundary="B_3668078282_1321163941" --B_3668078282_1321163941 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I concur: =20 Subject: Re: [Cfrg] Homomorphic Encryption Standardization =E2=80=93 Side Meeting =20 On Wed, Mar 25, 2020 at 5:03 PM Yaron Sheffer wrote= : Apologies for cross-posting. Dear IETFers, We would like to introduce the work of the Homomorphic Encryption Standardi= zation consortium [1] to the IETF and IRTF community, and solicit feedback a= bout the next steps to standardize this encryption technology. This was orig= inally intended as an IETF-107 side meeting, instead we will hold it as a vi= rtual meeting the week after IETF-107. Date/time: Tue March 31, 10:00-11:00 PST, 13:00-14:00 EST, 17:00-18:00 UTC,= 20:00-21:00 IL. =20 I would like to see this brought into IRTF as soon as possible either as pa= rt of CFRG or as a separate effort. =20 Right now the canon of commercial cryptography uses only the primitives dev= eloped up to 1990 (hash chains). I am currently trying to persuade people to= make use of threshold cryptography techniques that were developed in the mi= d 90s. We need to get out of the habit of waiting 25 years for new cryptogra= phic primitives to mature before we start looking at them. =20 We should stop asking 'does anyone need this' and instead ask 'is this usef= ul'. =20 The other reason for bringing it into IRTF is that we really do need a clea= r IPR regime or else things can get ugly and efforts can stall. =20 =20 --B_3668078282_1321163941 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I concur:

&n= bsp;

Subject: Re: [Cfrg] Homomorphic Encryption Standardization =E2=80=93 S= ide Meeting

 

On Wed, Mar 25, 2020 at= 5:03 PM Yaron Sheffer <yaronf.iet= f@gmail.com> wrote:

Apologies for cross-posting.

Dear IETFers,

We would like= to introduce the work of the Homomorphic Encryption Standardization consort= ium [1] to the IETF and IRTF community, and solicit feedback about the next = steps to standardize this encryption technology. This was originally intende= d as an IETF-107 side meeting, instead we will hold it as a virtual meeting = the week after IETF-107.

Date/time: Tue March 31, 10:00-11:00 PST, 13= :00-14:00 EST, 17:00-18:00 UTC, 20:00-21:00 IL.

<= div>

 

<= div>

I would like to see this brought into IRTF as soon as possible eithe= r as part of CFRG or as a separate effort.

<= p class=3DMsoNormal style=3D'margin-left:.5in'> 

Right now the canon of commercial crypto= graphy uses only the primitives developed up to 1990 (hash chains). I am cur= rently trying to persuade people to make use of threshold cryptography techn= iques that were developed in the mid 90s. We need to get out of the habit of= waiting 25 years for new cryptographic primitives to mature before we start= looking at them.

 

We should stop asking 'does anyone need this' and instead ask 'is= this useful'.

 

The other reason for bringing it into IRTF is that we really do need= a clear IPR regime or else things can get ugly and efforts can stall.<= /o:p>

 = ;

 

--B_3668078282_1321163941-- --B_3668078282_1073986792 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQAEsOl/1qhyyOFZzgAAAASw6TANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTIwMDIxMjE2NTAyM1oXDTI1MDIx MDE2NTAyM1owYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCmeoHpDu+bGes6qLPIUd2r7EQaBwYt V254WjhvNdMry3tev5DNk7FprxZhspY0dxRoDvIUrfJ3saAcbxrVc9HnzdNTl57rtF2RiRLM Fb7wL6yz4Yis3yY6GpbONzkKX5FajFmSGuktYMMVt8CAPcPbbkUMPZ80QzMxWYolvcYH+C4z eH8Zw/oU7bzunibn0hJISHDZhNJyewLtQEhRxSHf/278CbuAbWq0YHVRwTz7Wd4FpFIvXdxj 6+c4QTMSTtWGvTNPtrYokw8g1SvZhZKYswnWHGOjGC5dr4NBfreyMq3f7y0x8Tp9dpJuDcK9 UMAMY3C0HZrNng3Y+tSc4XrhAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUaBwMva1XkRg3VVpo HkGTEOInxwEwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCjAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBACYoq8k4 439LiS2zazVa7DYys6kPXsJaEVjmRmOZYOIeMA0fDV2qoKa27RnGhRvxgER7MYtiNsj95qUx EM3Ov0xnNLZONOsEYRlfdy8oR25TnuEGaVIbxqK38dYGzY0Zy2/2ZjptkXgyH6h3E50s43lr ZSm2KK39qS4o/3ZG7sPjzouWXj8lzMyQar4+2j2U3axuRlY17vXXSCGFYtUNZXWey+JhLWBf DK7EqpS811J3htiJS+eBWtkWMr6ZsnAvMWCdXZY+5Hy7qrpGUxKQA4MdFsATkPYTRE8c8u27 izPeEoZpm40nQGx+IElp1ojJDPekx2EmAbRszcbgGskh8LEwggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAA7OX5fo0OiIK0RAAAAADs5MA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMTgwODI4MjE0NTI5WhcNMjEwODI3 MjE0NTI5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI5Vc19RKc/69lmwhogDOjjzPQbmc8s6 Z6rzP6oUHAswDICqZWwPt+FTbKr0YTAqRNsTEN4YiW0fORK+fNRvClo0pdiCqj3DwDQZLRI4 Dak1yTsUtVe35oomQbXtO+0A0L/CowYri/UKeRG1i1/0cXSf4mAx0ed9wh2SordAb8o2FuOU 0B2ppnqjro1VFugHHX6QOggaeLFOprT5gnTZUmqM37/d4DGB9XDdTQi144zQSwSWKkaUThsy D9CHSRNcB79HBvlZGSM+BkIbayPdhQAuz4yKsOZEWPx/6LnMotzBevSswnCDf+u9ajCgMnje WbrZRN+xoYEuhycXyK2b8/MCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBTZUpq7Rsccv42yU9UQ 4wvojOl4pzAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgEJMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEACyN6 Yhi9LApOPpf60ypSV2WmV3sqnrsrdlPTW+am4wMK/M/5PZmt5jFVtXaErkWYdrbMdjeo2o/G 9N2DnrFOhz7kDYM9HC9AH/rWCfoSkI/C2N6Rq/uDnRJfao61wyv37qKtanNdkp+reyLxdVPn foVrD/VZli4UV28u4XBuYDkjXPyyiH+bb395FnxOtTA3Uz41Ohpdvr6oLPEuy0IP4MPfK5wD mS6GXcB+ze9sYEp+DJxE7WAbkW5Y536WPl/rfWm/k6ZC1KPVSRM7mS+atk44VOgzPLXkl6Tu 6zY8tMczfr5F0om1JfN8G50s4QDUGtsMgzW+LXVDhFD24xnUojGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQAEsOl/1qhyyOFZzgAAAASw6TANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCB8lqv6XhQVq5jbhRLp7XdOHsw2vhysG+PG6JPE Jcht+TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAzMjYx ODM4MDJaMA0GCSqGSIb3DQEBAQUABIIBAGZE2ZS4WJdg5fiXvOJYC9bqAsyw7xcyNJ+Ftbj3 R+nH3GWIIz0Wxc7HjgELgDBD5KjJ/D9JatX9IiDgbFSkzzVBDkjOUpgxdOAg4BlFU+ny/X3A 5ZSQJ1pAAolzXYdQJ79j1DcboOsQl+1iOoD5hkt2hJ8FvLojfPFDKX6trk9rNZcH5P/IOhtS eFMOzh7ccClQtKb8dilbTAhYGcGqMeCS28AiVKRVy7sSPJDOm7pZ42ugv2I3LbrcU8ik2vSM irMWgoZULm5+p8IB3GUQ2Hp3AXdvi8o09JyQE9a46/ylvg9ojjg//qSAv9C4LzyFZW3NFZJE 00621HxgRHgJNnY= --B_3668078282_1073986792-- From nobody Thu Mar 26 13:36:30 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9283A0D45; Thu, 26 Mar 2020 13:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=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 AQeT15bgmjlL; Thu, 26 Mar 2020 13:36:16 -0700 (PDT) Received: from mail-qv1-xf43.google.com (mail-qv1-xf43.google.com [IPv6:2607:f8b0:4864:20::f43]) (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 1956A3A00D9; Thu, 26 Mar 2020 13:35:55 -0700 (PDT) Received: by mail-qv1-xf43.google.com with SMTP id n1so3818534qvz.4; Thu, 26 Mar 2020 13:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:to:cc:references:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=eclucsqNQMQljfU4PkWVtZIqjnvDQgAi71V8nhs79Oc=; b=tD6As/FlfniwEP/CeCFFIU8RMI4bpQQwexNyTYoDrzFT6tcAhmnI+QHa/m5L+PEEO7 7x+5FK6m9/lM+acR0f7o5hvhaPemr5qu9eYvE3A58QZlucZBrji+NC4y5lOE4lHq/NWw YonWbNv44CWQlZhSNnZFOzn6hp93OpW7jMDYgIlU8M8sqP/5unF/hhtmjr94hv+BwnUl YH35bBQwUdBkrnXENQdqBJKW0Y5XtzfC9+baAqNMCJPFWLugzxQ/8/O1uMg4D55+APHn DfnwA7rKzDllGNZVXnLTyIBQN39ziilihCLsPVHzX8XF2m0NLNKkC+ljHPJjm234qbaL sRig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:cc:references :organization:message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=eclucsqNQMQljfU4PkWVtZIqjnvDQgAi71V8nhs79Oc=; b=gVMfIo7ox18rQhw83K+kmSqDTs2yc7fhEl1EjoMlrDrq30BBtqMACO7WmFazpmi7S6 ZjNbQXbEY9NV3jY82ATwzhdJg7Xvagwghvlf6CQTqsI+6iQbtEhL6Qtr0pQNFD1ZVyIM GwIl5bQcNZWQhvJ8VvVe+8EsJmutCiLLI3LXVm7MmpPGWoDWcKbkZ1jUNwQ/wrAa5K/c HwgNdSfuusdRLZGlV1GwTYwGo7ceZawqA/9g0wierLpjLTcGHiGcXcd84C60V6Tizm7w WtNO6fHGjQdS9x3HRqZcxQOA+SxRarK0VIKw/RG7b1OKkZkznfAK9aUZdBwhI+66yKDi 5l4A== X-Gm-Message-State: ANhLgQ2DF346/MuXII8SPkloXfm2EnbSUT0PO2LCGMnUPlERGNzst9vt Ik4eXusWQ//Ua+ycwH9rBOPDspr6 X-Google-Smtp-Source: ADFU+vtNgOBpQfrfFuAQnwknSEBEZ3SogRpI1PoMYsSRlI4IUHqWDfh8JWcrSPwAgNuecSoBM8GZwA== X-Received: by 2002:ad4:4662:: with SMTP id z2mr10175800qvv.227.1585254943890; Thu, 26 Mar 2020 13:35:43 -0700 (PDT) Received: from [192.168.1.53] (pool-70-106-222-98.clppva.fios.verizon.net. [70.106.222.98]) by smtp.gmail.com with ESMTPSA id o13sm2183235qkg.111.2020.03.26.13.35.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Mar 2020 13:35:43 -0700 (PDT) From: Tony Rutkowski X-Google-Original-From: Tony Rutkowski Reply-To: trutkowski@netmagic.com To: Phillip Hallam-Baker , Yaron Sheffer Cc: ietf , standards@homomorphicencryption.org, "cfrg@irtf.org" , Dave Thaler , "saag@ietf.org" , Kim Laine References: <94CED3F7-BEBF-4E1B-A6B6-F464742BFAD5@gmail.com> Organization: Netmagic Associates LLC Message-ID: <1b993d52-71e0-9e39-d637-8d2e82eec801@netmagic.com> Date: Thu, 26 Mar 2020 16:35:41 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------155AD6939AB94020A82B38A2" Content-Language: en-US Archived-At: Subject: Re: [saag] =?utf-8?q?=5BCfrg=5D_Homomorphic_Encryption_Standardizati?= =?utf-8?q?on_=E2=80=93_Side_Meeting?= X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 20:36:27 -0000 This is a multi-part message in MIME format. --------------155AD6939AB94020A82B38A2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Phil et al., You might be interested that there were no less than ten input documents on homomorphic encryption for new standards going into the SG17 meeting that just wrapped up today.  best, tony TD [ 2867-PLEN ] New baseline text for X.tfmpc: Technical framework for Secure Multi-Party Computation Editor TD [ 2897-PLEN ] Proposal for new work item: Security guidelines for FHE-based data collaboration in machine learning Rapporteur Q4/17 TD [ 2694-PLEN ] LS/i on Initial draft Supplement on Network 2030 Services: Capabilities, performance and design of new communications services for the Network 2030 applications [from ITU-T SG13] ITU-T Study Group 13 C [ 798 ] Revised baseline text for X.fdip, Framework of de-identification processing service for telecommunication service providers (for determination) Korea (Rep. of) C [ 859 ] Proposed Modifications to X.fdip (Framework of de-identification process for telecommunication service providers) United Kingdom TD [ 2850-PLEN ] Revised baseline text for X.fdip: Framework of de-identification process for telecommunication service providers Editor C [ 845 ] Proposal for new work item: Security guidelines for FHE-based machine learning Electronics and Telecommunications Research Institute (ETRI) (Korea (Rep. of)) TD [ 2529-PLEN ] LS/i/r on AI (Artificial Intelligence)/ML (Machine Learning) and security (SG17-LS142) [from FG-AI4H] FG-AI4H TD [ 2936-PLEN ] LS/o/r on AI (Artificial Intelligence)/ML (Machine Learning) and security (reply to FG-AI4H-LS1) [from FG-AI4H] ITU-T Study Group 17 C [ 776 ] Revised baseline text for X.sra-dlt : Security framework to Distributed Ledger Technology Korea (Rep. of) On 2020-03-26 2:22 PM, Phillip Hallam-Baker wrote: > On Wed, Mar 25, 2020 at 5:03 PM Yaron Sheffer > wrote: > > Apologies for cross-posting. > > Dear IETFers, > > We would like to introduce the work of the Homomorphic Encryption > Standardization consortium [1] to the IETF and IRTF community, and > solicit feedback about the next steps to standardize this > encryption technology. This was originally intended as an IETF-107 > side meeting, instead we will hold it as a virtual meeting the > week after IETF-107. > > Date/time: Tue March 31, 10:00-11:00 PST, 13:00-14:00 EST, > 17:00-18:00 UTC, 20:00-21:00 IL. > > > I would like to see this brought into IRTF as soon as possible either > as part of CFRG or as a separate effort. > > Right now the canon of commercial cryptography uses only the > primitives developed up to 1990 (hash chains). I am currently trying > to persuade people to make use of threshold cryptography techniques > that were developed in the mid 90s. We need to get out of the habit of > waiting 25 years for new cryptographic primitives to mature before we > start looking at them. > > We should stop asking 'does anyone need this' and instead ask 'is this > useful'. > > The other reason for bringing it into IRTF is that we really do need a > clear IPR regime or else things can get ugly and efforts can stall. > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --------------155AD6939AB94020A82B38A2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Phil et al.,

You might be interested that there were no less than ten input documents on homomorphic encryption for new standards going into the SG17 meeting that just wrapped up today.  best, tony

TD [ 2867-PLEN ]   New baseline text for X.tfmpc: Technical framework for Secure Multi-Party Computation     Editor  
TD [ 2897-PLEN ]   Proposal for new work item: Security guidelines for FHE-based data collaboration in machine learning     Rapporteur Q4/17  
TD [ 2694-PLEN ]   LS/i on Initial draft Supplement on Network 2030 Services: Capabilities, performance and design of new communications services for the Network 2030 applications [from ITU-T SG13]     ITU-T Study Group 13  
C [ 798 ]   Revised baseline text for X.fdip, Framework of de-identification processing service for telecommunication service providers (for determination)     Korea (Rep. of)  
C [ 859 ]   Proposed Modifications to X.fdip (Framework of de-identification process for telecommunication service providers)   United Kingdom  
TD [ 2850-PLEN ]   Revised baseline text for X.fdip: Framework of de-identification process for telecommunication service providers     Editor  
C [ 845 ]   Proposal for new work item: Security guidelines for FHE-based machine learning     Electronics and Telecommunications Research Institute (ETRI) (Korea (Rep. of))  
TD [ 2529-PLEN ]   LS/i/r on AI (Artificial Intelligence)/ML (Machine Learning) and security (SG17-LS142) [from FG-AI4H]     FG-AI4H  
TD [ 2936-PLEN ]   LS/o/r on AI (Artificial Intelligence)/ML (Machine Learning) and security (reply to FG-AI4H-LS1) [from FG-AI4H]     ITU-T Study Group 17  
C [ 776 ]   Revised baseline text for X.sra-dlt : Security framework to Distributed Ledger Technology     Korea (Rep. of)  


On 2020-03-26 2:22 PM, Phillip Hallam-Baker wrote:
On Wed, Mar 25, 2020 at 5:03 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Apologies for cross-posting.

Dear IETFers,

We would like to introduce the work of the Homomorphic Encryption Standardization consortium [1] to the IETF and IRTF community, and solicit feedback about the next steps to standardize this encryption technology. This was originally intended as an IETF-107 side meeting, instead we will hold it as a virtual meeting the week after IETF-107.

Date/time: Tue March 31, 10:00-11:00 PST, 13:00-14:00 EST, 17:00-18:00 UTC, 20:00-21:00 IL.

I would like to see this brought into IRTF as soon as possible either as part of CFRG or as a separate effort.

Right now the canon of commercial cryptography uses only the primitives developed up to 1990 (hash chains). I am currently trying to persuade people to make use of threshold cryptography techniques that were developed in the mid 90s. We need to get out of the habit of waiting 25 years for new cryptographic primitives to mature before we start looking at them.

We should stop asking 'does anyone need this' and instead ask 'is this useful'.

The other reason for bringing it into IRTF is that we really do need a clear IPR regime or else things can get ugly and efforts can stall.

 

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--------------155AD6939AB94020A82B38A2-- From nobody Sat Mar 28 09:30:37 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1383A03F3 for ; Sat, 28 Mar 2020 09:30:36 -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, SPF_HELO_NONE=0.001, 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=wesleyan.edu 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 FBNkJh4scR6x for ; Sat, 28 Mar 2020 09:30:34 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 50ADC3A003B for ; Sat, 28 Mar 2020 09:30:34 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id q128so13060152iof.9 for ; Sat, 28 Mar 2020 09:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wesleyan.edu; s=wesgmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DrLkF6vA0zg5BNgZP6p+zsKXrAmeLy65VHktNEmeN+s=; b=MG2IgTixoBgAn4LhmyspXOgdg/aZeHzmOWM21/hg2AcJc9KVaZfne009EhJV8bg5TC 6IoQ2TmVPRE2Pu7C0NkQDj9z4j2CZ5QCOnSJFdWi9V1D9dpE7q0H1WhmY9u9AEEB+jCh E7ffhsrMjnFnVK8uD6PoL805VnOQXHVDft8WI= 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; bh=DrLkF6vA0zg5BNgZP6p+zsKXrAmeLy65VHktNEmeN+s=; b=PBwu3/MzrKwleNNojs/VW9YCpUraJ9YahG76TUBTSPI7/rD6FSMfvl888o9ZO3T5Im 1FzrZa3ciD39GvAglgXwtEndpmq+3jUm/lgrsh9t581hPEVYgoHl4cDRVzmS98tQR+yh PIvX6JZ6L6+fKS4QswwjdH8Kz0nbDtd98npr6D31eHVbrnIHpkH29sGZz24DViXkkPUV QMmZBIV/I+b/esCNBOZzOfDn5ExVtmM/YX8jJl5ZW8mJ3zo+geUV7P/VIOB+k/Tbvs8/ zXoV+PSsHVcXp67Rdw7yxv9UHc+oJw24+1Axe7+7YEWPz5dQUZafX+QSbyyt2YvpWcIN E6/g== X-Gm-Message-State: ANhLgQ12cItoVv9rN/Y3i7r6Eq87XrweJKCSDMyicrgM5iSiKIEGD3go EFSFH6LyQyknBEUHYOLKN0g+Y6ndKwBDyz9KW+azDA== X-Google-Smtp-Source: ADFU+vvCDb09tGbsGU6K3ikMjMyqeJlhzutZNFfTkNxSs7/nqZ+aaM9EfXWRp7KERielKom+kNTSl3oTb0breXGKUFM= X-Received: by 2002:a02:cbb6:: with SMTP id v22mr3789030jap.78.1585413033438; Sat, 28 Mar 2020 09:30:33 -0700 (PDT) MIME-Version: 1.0 References: <30262.1585340495@localhost> In-Reply-To: <30262.1585340495@localhost> From: Sebastian Zimmeck Date: Sat, 28 Mar 2020 12:30:21 -0400 Message-ID: To: Michael Richardson , saag@ietf.org Content-Type: multipart/alternative; boundary="000000000000ae49fd05a1ecbc36" Archived-At: Subject: Re: [saag] CCPA Do-Not-Sell X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 16:30:37 -0000 --000000000000ae49fd05a1ecbc36 Content-Type: text/plain; charset="UTF-8" Sure. There are two California laws: the California Online Privacy Protection Act (CalOPPA), effective as of July 1, 2004, and the California Consumer Privacy Act (CCPA), effective as of January 1, 2020. Per CalOPPA an operator of an online service must "[d]isclose how the operator responds to Web browser 'do not track' signals or other mechanisms that provide consumers the ability to exercise choice regarding the collection of personally identifiable information ... ." That is, CalOPPA does not require the operator to comply with the DNT signal. It only requires the operator to *say* whether it complies. This law is the reason why you find the DNT signals in many privacy policies mentioned, but in a nicely worded way saying that it will not be respected. In conjunction with CalOPPA's DNT requirement, the W3C DNT Working Group formalized the DNT signal. Currently, Firefox is still supporting it, and users can set the DNT header in the browser preferences. The CCPA introduced new rights for California consumers, particularly, the right to object to the sale of information. Recently, the Office of the California Attorney General drafted regulations that actually require that a business must comply with automatic Do-Not-Sell signals. It is not enough for a business to say whether it complies, but it must actually comply. That is the big difference. What the exact relationship between the DNT and the Do-Not-Sell signal is at this point is not clear. Some commentators on the regulations suggested that a DNT signal should be interpreted as a Do-Not-Sell signal. Others see these as separate. On the naming, I agree. It would be better to not use DNS as an abbreviation for Do-Not-Sell. Maybe, DNSell or something similar. Best regards, Sebastian _______________________________________________ Check out PrivacyFlash Pro Developed at the privacy-tech-lab , Wesleyan University On Fri, Mar 27, 2020 at 4:21 PM Michael Richardson wrote: > Sebastian Zimmeck wrote: > > I am interested in setting up a working group on such device > controls. The > > Do-Not-Sell signal could be similar to a Do-Not-Track (DNT) signal. > > However, the difference is that recipients of the DNT signal were not > > required to comply with the signal. Rather, they only needed to > *say* whether > > they would comply; per the California Online Privacy Protection Act > > (CalOPPA). > > I didn't understand this part. > Can you use reply to the list and use more words, or give me an example? > > "Do-Not-Sell" == DNS. Could be confusing. > > --000000000000ae49fd05a1ecbc36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sure. There are two California laws: the = California Online Privacy Protection Act (CalOPPA), effective as of July 1,= 2004, and the California Consumer Privacy Act (CCPA), effective as of Janu= ary 1, 2020. Per CalOPPA an operator of an online service must=C2=A0
<= div dir=3D"ltr">=C2=A0
"[d]isclose how the opera= tor responds to Web browser 'do not track' signals or other mechani= sms that provide consumers the ability to exercise choice regarding the col= lection of personally identifiable information ... ."

That is, CalOPPA does not require the operator to = comply with the DNT signal. It only requires the operator to *say* whether = it complies. This law is the reason why you find the DNT signals in many pr= ivacy policies mentioned, but in a nicely worded way saying that it will no= t be respected. In conjunction with CalOPPA's DNT requirement, the W3C = DNT Working Group formalized the DNT signal. Currently, Firefox is still su= pporting it, and users can set the DNT header in the browser preferences.

The CCPA introduced new rights for California consu= mers, particularly, the right to object to the sale of information. Recentl= y, the Office of the California Attorney General drafted regulations that a= ctually require that a business must comply with automatic Do-Not-Sell sign= als. It is not enough for a business to say whether it complies, but it mus= t actually comply. That is the big difference.

Wha= t the exact relationship between the DNT and the Do-Not-Sell signal is at t= his point is not clear. Some commentators on the regulations suggested that= a DNT signal should be interpreted as a Do-Not-Sell signal. Others see the= se as separate.

On the naming, I agree. It would b= e better to not use DNS as an abbreviation for Do-Not-Sell. Maybe, DNSell o= r something similar.

Best regards,

Sebastian

_______________________________________________
Check out=C2=A0= PrivacyFlash Pro
<= /div>


On Fri, Mar 27, 2020 at 4:21 P= M Michael Richardson <mcr@sandelman.= ca> wrote:
szimmeck@wesleyan.edu> wrote:
=C2=A0 =C2=A0 > I am interested in setting up a working group on such de= vice controls. The
=C2=A0 =C2=A0 > Do-Not-Sell signal could be similar to a Do-Not-Track (D= NT) signal.
=C2=A0 =C2=A0 > However, the difference is that recipients of the DNT si= gnal were not
=C2=A0 =C2=A0 > required to comply with the signal. Rather, they only ne= eded to *say* whether
=C2=A0 =C2=A0 > they would comply; per the California Online Privacy Pro= tection Act
=C2=A0 =C2=A0 > (CalOPPA).

I didn't understand this part.
Can you use reply to the list and use more words, or give me an example?
"Do-Not-Sell" =3D=3D DNS. Could be confusing.

--000000000000ae49fd05a1ecbc36--