From nobody Mon Feb 3 13:06:27 2020 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0890120CB7 for ; Mon, 3 Feb 2020 13:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.435 X-Spam-Level: * X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, 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 ccyqjq-MxPyI for ; Mon, 3 Feb 2020 13:06:24 -0800 (PST) Received: from fe3.cityemail.com (mail-ob3.cityemail.com [104.128.152.20]) by ietfa.amsl.com (Postfix) with ESMTP id 43379120CAF for ; Mon, 3 Feb 2020 13:06:24 -0800 (PST) Received: (qmail 24669 invoked from network); 3 Feb 2020 21:06:23 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe3.cityemail.com with (AES128-SHA encrypted) SMTP (088cb258-46c9-11ea-90b2-8fbe104effc4); Mon, 03 Feb 2020 13:06:23 -0800 To: art@ietf.org From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <55abf67e-6a90-acff-a832-87a168d50522@linuxmagic.com> Date: Mon, 3 Feb 2020 13:06:23 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-MagicMail-OS: Linux 2.2.x-3.x X-MagicMail-UUID: 088cb258-46c9-11ea-90b2-8fbe104effc4 X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: [art] [FEEDBACK REQUEST] "Birds of a Feather" topic, email security threats X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 21:06:26 -0000 Call for Feedback: "Birds of a Feather (BOF)" on email authentication security. As some may know, we have a couple of IETF Drafts looking for a Working Group home, but because it crosses over several protocols, discussions on these can extend beyond groups which cover only one protocol. There are some issues that extend across the ecosystem. These (our) drafts are related to email security, but as we look at this serious problem (email compromises), I believe it might be time to look at the problem in a wider scope, so I am looking at having a "Birds of a Feather" meeting proposal, that can encompass a wider discussion on IETF involvement in these issues. For instance, aside from our IETF drafts on CLIENTID extensions/enhancements for IMAP/SMTP AUTH, (for those not familiar, references at the bottom), there are other things that could be addressed in such a meeting. * POP/SMTP authentication sent unencrypted over the network * AutoDiscovery should NEVER test unencrypted methods * Email Clients should deprecate the above * Other ideas to address email compromise risks worldwide? Given that in todays climate, of millions of compromised devices on the internet designed to 'sniff' traffic, sending authentication over the clear IMHO should NOT be recommended or referenced in RFC's, otherwise vendors will continue to support these. We still see 'pop connectors' by 3rd parties, various auto-discovery methods that attempt to connect using POP 110, all whom send email credentials in the clear, risking unintended exposure of this data. All modern email clients have a role in protecting users, and by supporting such legacy methods, these risks will continue. While some new RFC materials cover the SHOULD be over encrypted, and some cover recommendations, a larger discussion in general over whether updates should occur, to deprecate language that would allow for insecure transmission of authentication protocols. And aside from our own methods to make a more transparent form of native ability in legacy protocols to support tokens that be sent before authentication credentials are received, to allow systems, users, and authentication tools to decide whether to accept authentication requests unless supported by a recognized token, there may be others working on improvements in security that crossed protocol boundaries, or address other security related threats in email. My question to the list is this: * How wide/narrow should the topic/mandate be? -- Email Authentication & Security -- Communication Authentication Security -- POP/IMAP/SMTP Authentication -- POP/IMAP/SMTP Policies And Considerations I look forward to your feedback and suggestions, but note we only have a few days left to decide on the scope, in order to to request this BOF at the Vancouver EITF meeting in March. -- Michael -- For those not informed, we are looking for a home as well to discuss our CLIENTID initiatives https://datatracker.ietf.org/doc/draft-storey-smtp-client-id/?include_text=1 https://tools.ietf.org/html/draft-yu-imap-client-id-03 -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Mon Feb 3 13:40:03 2020 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987F112006E for ; Mon, 3 Feb 2020 13:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 1ejcnjcitoyv for ; Mon, 3 Feb 2020 13:40:00 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94FAC12001E for ; Mon, 3 Feb 2020 13:40:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E5B35BE20; Mon, 3 Feb 2020 21:39:56 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRAKvESdxhnV; Mon, 3 Feb 2020 21:39:55 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4FC1BBDCF; Mon, 3 Feb 2020 21:39:55 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1580765995; bh=RQsMGjgs9pgQ07pCqh5qMvK8Vh4kuRi1L7oWpLGV3jc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=JD9F6u5wAXY/UnkXJEmE30YutpeaxyZQpzpEhS7PtyKn6XHCKXBLAmQzOOlu4/Q30 9rWZe/oNfcbyyMgoq7koVM0SUCaa0pv05NIVCaN127uU+26YKCaw/pErR4e1A6bukD LCYjwSmiFm44jxHnw+ENaOswuYURQiUUrwmWksEQ= To: Michael Peddemors , art@ietf.org References: <55abf67e-6a90-acff-a832-87a168d50522@linuxmagic.com> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Mon, 3 Feb 2020 21:39:54 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <55abf67e-6a90-acff-a832-87a168d50522@linuxmagic.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6LLAdmXgPRssP1I05clnCxzlEEnJR4atw" Archived-At: Subject: Re: [art] [FEEDBACK REQUEST] "Birds of a Feather" topic, email security threats X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 21:40:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6LLAdmXgPRssP1I05clnCxzlEEnJR4atw Content-Type: multipart/mixed; boundary="43m2Et0dSHI4hXARU5JejPgCQm2YdVOvW"; protected-headers="v1" From: Stephen Farrell To: Michael Peddemors , art@ietf.org Message-ID: Subject: Re: [art] [FEEDBACK REQUEST] "Birds of a Feather" topic, email security threats References: <55abf67e-6a90-acff-a832-87a168d50522@linuxmagic.com> In-Reply-To: <55abf67e-6a90-acff-a832-87a168d50522@linuxmagic.com> --43m2Et0dSHI4hXARU5JejPgCQm2YdVOvW Content-Type: multipart/mixed; boundary="------------A6FCBB59CB7B5465BD759255" Content-Language: en-US This is a multi-part message in MIME format. --------------A6FCBB59CB7B5465BD759255 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 03/02/2020 21:06, Michael Peddemors wrote: > "Birds=C2=A0of=C2=A0a=C2=A0Feather=C2=A0(BOF)"=C2=A0on=C2=A0email=C2=A0= authentication=C2=A0security. I'd love to see improvements in IMAP for countering password guessing attacks from random sources. I'm not sure how well 2FA schemes are supported in IMAP myself but I think something like that would be good if widely and easily deployed. TBH though, I'm very unsure how likely it would be that such improvements would get deployed in major clients, servers and services but it'd be good if they were. (I was at a meeting recently where IMAP was described by a small mail operator as a "legacy protocol" when compared to a proprietary one from their fav. vendor that does support 2FA;-() I'm also not clear that sending more long-lived identifiers about is at all the right approach (in particular not MAC addresses and the like!). So even if the problem is a good BoF topic, I dunno if the approach in draft-yu is what I'd like to see happen. (That's based on a v. quick scan of only that draft, sorry if I've gotten the wrong end of the stick!) Anyway FWIW, I'd go along to a bar BoF or formal BoF on this topic. Cheers, S. --------------A6FCBB59CB7B5465BD759255 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------A6FCBB59CB7B5465BD759255-- --43m2Et0dSHI4hXARU5JejPgCQm2YdVOvW-- --6LLAdmXgPRssP1I05clnCxzlEEnJR4atw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl44kyoACgkQWrL68XsX K+oniA//XLQybIvJ8ndf6bd7uw/CTQjBxLQuetEvscXw4TnR2Cp04D8H0hRk2xeF sc8LaD3jVdPiqHoxL4wmd8mHfO/s/lRA6rup0ms+U22+SoA0FHcx0ui/DO+rIUm8 r9P0hxVeK7asFr+Svwm8zHIHOjZUhgRyhbJE28xhwzGQ2i6SK7NO6yDKen/T+9En H5bB+UStScWKxg+eaK3+D7wguo1Vnllj9g/kpxss0GCMNulyaU6wd7kxcqVzxrqs keivgT7g6ssW4NS4BXb5JQxccvD93KlPaYZ3HV6Zfw/8j/mNC8OVw5sJxChL/Esp GLwmd0bAwWpFmAveI0JvJiqTwp6uf8zJHSbYcZOCcFn544qbiKDfCf+xsA8Oqbm1 Qi43+X3QnpLwp9iHntxtfGeM/dbGUC0JjD5UtkasRl5XUwO9xjzmqUrWmjhGW0m0 KJ0RSPRjjgohwvtOORyfbw7Mggh6ZIqi1dpiaTVQNgTt/1PQf1F1MIi80JABrlX2 lkQVjfn7kqav544Mlcd43Zy6dez0DAJl26r8c1Z8jqTCnWbzJfDC2XpKQk9/1chL PLSK+M61MqLLzAmPFtGhj0+OJJ9h3Rg+Q5vbdrsF3m4pPFVR2omybQh3gNdwT5g0 xn0B8SiGqHmnr++F818AQQTJSBPF03SmwSE5qdmjhnjRvkHxmWY= =PwkR -----END PGP SIGNATURE----- --6LLAdmXgPRssP1I05clnCxzlEEnJR4atw-- From nobody Mon Feb 3 14:45:08 2020 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D7F120044 for ; Mon, 3 Feb 2020 14:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 GyLNEPzrFTiS for ; Mon, 3 Feb 2020 14:45:03 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B308612006E for ; Mon, 3 Feb 2020 14:45:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4951; q=dns/txt; s=iport; t=1580769902; x=1581979502; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=tPf6/Fuqq4ORX8nZeE+LmFz7Oss1aVL1B3ZlpdcbjLM=; b=b8GL7jL00FXWzEaRuQv6W4uIsO9XKB2m2y/LFUZXvVuVBTVCKq+d/a8R bDnMCrLE7X4V+I7VfdnNDA9tQUs38BfKNybrLgFLpdKQKaoMBrcPvYC9R upZOMwqq9hOD7y0AqzKBawcOp8Wh/yP6U1PWKMXTnkvVLto1StJczfx+/ o=; X-IPAS-Result: =?us-ascii?q?A0DkBwAMojhe/xbLJq1cBgMeAQschRBQBAEgEiqEFIkDh?= =?us-ascii?q?3klmVGBZwkBAQEMAQEYDQoBAYRAAoJYOBMCAwEBAQMCAwEBAQEEAQEBAgEFB?= =?us-ascii?q?G2FNwyFZgEBAQECAQEBGwYyEQgLBQsLGAICJgICJzAGE4MmAYJbIA+sJnWBM?= =?us-ascii?q?oQ5Ag5BQIR9gQ4qgiOGCYIhgTY3ggCBEScMFIJMPmsZAYFfAQECAQEYgQsJA?= =?us-ascii?q?QgKASEhJoJJMoIsBI1BARyiBIJFgk6EeIVHhCgGgkCCRRuCSIgOhCGMEZdIj?= =?us-ascii?q?wWDLgIEBgUCFXhxImdxMxoIGxU7KgGCQQk1EhgNjjWDB1SFFIVAQAMwjFeCM?= =?us-ascii?q?gEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.70,398,1574121600"; d="scan'208";a="20603196" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Feb 2020 22:44:58 +0000 Received: from [10.61.163.150] ([10.61.163.150]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 013Miusq001568 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Feb 2020 22:44:56 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Eliot Lear In-Reply-To: <55abf67e-6a90-acff-a832-87a168d50522@linuxmagic.com> Date: Mon, 3 Feb 2020 23:44:55 +0100 Cc: art@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <298521FA-CC31-4888-99E3-7FE32419679C@cisco.com> References: <55abf67e-6a90-acff-a832-87a168d50522@linuxmagic.com> To: Michael Peddemors X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Outbound-SMTP-Client: 10.61.163.150, [10.61.163.150] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [art] [FEEDBACK REQUEST] "Birds of a Feather" topic, email security threats X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 22:45:06 -0000 Hi Michael, IMHO the issue is not one of client identity, but rather = preauthorization versus non-prearranged communication. As to your = recommendations below, while there=E2=80=99s nothing wrong with them, = even if you implemented them, I do not believe that spam would be = reduced one iota. I would suggest that one delve a bit into per-destination = preauthorization and how that might work from a UX perspective. In any case, I=E2=80=99m not sure a formal BoF is called for at this = point. Maybe a bar bof. Eliot > On 3 Feb 2020, at 22:06, Michael Peddemors = wrote: >=20 > Call for Feedback: >=20 > "Birds of a Feather (BOF)" on email authentication security. >=20 > As some may know, we have a couple of IETF Drafts looking for a = Working Group home, but because it crosses over several protocols, = discussions on these can extend beyond groups which cover only one = protocol. There are some issues that extend across the ecosystem. >=20 > These (our) drafts are related to email security, but as we look at = this serious problem (email compromises), I believe it might be time to = look at the problem in a wider scope, so I am looking at having a "Birds = of a Feather" meeting proposal, that can encompass a wider discussion on = IETF involvement in these issues. >=20 > For instance, aside from our IETF drafts on CLIENTID = extensions/enhancements for IMAP/SMTP AUTH, (for those not familiar, = references at the bottom), there are other things that could be = addressed in such a meeting. >=20 > * POP/SMTP authentication sent unencrypted over the network > * AutoDiscovery should NEVER test unencrypted methods > * Email Clients should deprecate the above > * Other ideas to address email compromise risks worldwide? >=20 > Given that in todays climate, of millions of compromised devices on = the internet designed to 'sniff' traffic, sending authentication over = the clear IMHO should NOT be recommended or referenced in RFC's, = otherwise vendors will continue to support these. We still see 'pop = connectors' by 3rd parties, various auto-discovery methods that attempt = to connect using POP 110, all whom send email credentials in the clear, = risking unintended exposure of this data. >=20 > All modern email clients have a role in protecting users, and by = supporting such legacy methods, these risks will continue. >=20 > While some new RFC materials cover the SHOULD be over encrypted, and = some cover recommendations, a larger discussion in general over whether = updates should occur, to deprecate language that would allow for = insecure transmission of authentication protocols. >=20 > And aside from our own methods to make a more transparent form of = native ability in legacy protocols to support tokens that be sent before = authentication credentials are received, to allow systems, users, and = authentication tools to decide whether to accept authentication requests = unless supported by a recognized token, there may be others working on = improvements in security that crossed protocol boundaries, or address = other security related threats in email. >=20 > My question to the list is this: >=20 > * How wide/narrow should the topic/mandate be? >=20 > -- Email Authentication & Security > -- Communication Authentication Security > -- POP/IMAP/SMTP Authentication > -- POP/IMAP/SMTP Policies And Considerations >=20 >=20 > I look forward to your feedback and suggestions, but note we only have = a few days left to decide on the scope, in order to to request this BOF = at the Vancouver EITF meeting in March. >=20 > -- Michael -- >=20 >=20 > For those not informed, we are looking for a home as well to discuss = our CLIENTID initiatives >=20 > = https://datatracker.ietf.org/doc/draft-storey-smtp-client-id/?include_text= =3D1 > https://tools.ietf.org/html/draft-yu-imap-client-id-03 >=20 >=20 >=20 > --=20 > "Catch the Magic of Linux..." > = ------------------------------------------------------------------------ > Michael Peddemors, President/CEO LinuxMagic Inc. > Visit us at http://www.linuxmagic.com @linuxmagic > A Wizard IT Company - For More Info http://www.wizard.ca > "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices = Ltd. > = ------------------------------------------------------------------------ > 604-682-0300 Beautiful British Columbia, Canada >=20 > This email and any electronic data contained are confidential and = intended > solely for the use of the individual or entity to which they are = addressed. > Please note that any views or opinions presented in this email are = solely > those of the author and are not intended to represent those of the = company. >=20 > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art From nobody Mon Feb 3 14:54:14 2020 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D8F12007C for ; Mon, 3 Feb 2020 14:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.228 X-Spam-Level: ** X-Spam-Status: No, score=2.228 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, RDNS_NONE=0.793, 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 VTjdgU2J6vBO for ; Mon, 3 Feb 2020 14:54:10 -0800 (PST) Received: from fe3.cityemail.com (unknown [104.128.152.20]) by ietfa.amsl.com (Postfix) with ESMTP id CEBDE12001B for ; Mon, 3 Feb 2020 14:54:10 -0800 (PST) Received: (qmail 15242 invoked from network); 3 Feb 2020 22:54:10 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe3.cityemail.com with (AES128-SHA encrypted) SMTP (170f2b62-46d8-11ea-a7de-2f6235286947); Mon, 03 Feb 2020 14:54:10 -0800 To: Eliot Lear Cc: art@ietf.org References: <55abf67e-6a90-acff-a832-87a168d50522@linuxmagic.com> <298521FA-CC31-4888-99E3-7FE32419679C@cisco.com> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <4150b6d5-ab85-ba54-f36e-96d36fb65026@linuxmagic.com> Date: Mon, 3 Feb 2020 14:54:10 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <298521FA-CC31-4888-99E3-7FE32419679C@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: 170f2b62-46d8-11ea-a7de-2f6235286947 X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: Re: [art] [FEEDBACK REQUEST] "Birds of a Feather" topic, email security threats X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 22:54:12 -0000 On 2020-02-03 2:44 p.m., Eliot Lear wrote: > Hi Michael, > > IMHO the issue is not one of client identity, but rather preauthorization versus non-prearranged communication. As to your recommendations below, while there’s nothing wrong with them, even if you implemented them, I do not believe that spam would be reduced one iota. > > I would suggest that one delve a bit into per-destination preauthorization and how that might work from a UX perspective. > > In any case, I’m not sure a formal BoF is called for at this point. Maybe a bar bof. > > Eliot I do want to point out, this is not about spam, but rather email security, unless you are recommending that we enlarge the topic that much? And BTW, for the record the CLIENTID is only one of many email security related topics that might be discussed. Looking in general to see if others think that there are important things to add/avoid in this topic for a BOF. (off thread, sending authorization is about validating ones identity to access an email resource, CLIENTID is a step in that direction, when used to that affect, but it can also relate to a class of allowed/expected devices that can access/authenticate to access a resource) > > > >> On 3 Feb 2020, at 22:06, Michael Peddemors wrote: >> >> Call for Feedback: >> >> "Birds of a Feather (BOF)" on email authentication security. >> >> As some may know, we have a couple of IETF Drafts looking for a Working Group home, but because it crosses over several protocols, discussions on these can extend beyond groups which cover only one protocol. There are some issues that extend across the ecosystem. >> >> These (our) drafts are related to email security, but as we look at this serious problem (email compromises), I believe it might be time to look at the problem in a wider scope, so I am looking at having a "Birds of a Feather" meeting proposal, that can encompass a wider discussion on IETF involvement in these issues. >> >> For instance, aside from our IETF drafts on CLIENTID extensions/enhancements for IMAP/SMTP AUTH, (for those not familiar, references at the bottom), there are other things that could be addressed in such a meeting. >> >> * POP/SMTP authentication sent unencrypted over the network >> * AutoDiscovery should NEVER test unencrypted methods >> * Email Clients should deprecate the above >> * Other ideas to address email compromise risks worldwide? >> >> Given that in todays climate, of millions of compromised devices on the internet designed to 'sniff' traffic, sending authentication over the clear IMHO should NOT be recommended or referenced in RFC's, otherwise vendors will continue to support these. We still see 'pop connectors' by 3rd parties, various auto-discovery methods that attempt to connect using POP 110, all whom send email credentials in the clear, risking unintended exposure of this data. >> >> All modern email clients have a role in protecting users, and by supporting such legacy methods, these risks will continue. >> >> While some new RFC materials cover the SHOULD be over encrypted, and some cover recommendations, a larger discussion in general over whether updates should occur, to deprecate language that would allow for insecure transmission of authentication protocols. >> >> And aside from our own methods to make a more transparent form of native ability in legacy protocols to support tokens that be sent before authentication credentials are received, to allow systems, users, and authentication tools to decide whether to accept authentication requests unless supported by a recognized token, there may be others working on improvements in security that crossed protocol boundaries, or address other security related threats in email. >> >> My question to the list is this: >> >> * How wide/narrow should the topic/mandate be? >> >> -- Email Authentication & Security >> -- Communication Authentication Security >> -- POP/IMAP/SMTP Authentication >> -- POP/IMAP/SMTP Policies And Considerations >> >> >> I look forward to your feedback and suggestions, but note we only have a few days left to decide on the scope, in order to to request this BOF at the Vancouver EITF meeting in March. >> >> -- Michael -- >> >> >> For those not informed, we are looking for a home as well to discuss our CLIENTID initiatives >> >> https://datatracker.ietf.org/doc/draft-storey-smtp-client-id/?include_text=1 >> https://tools.ietf.org/html/draft-yu-imap-client-id-03 >> >> >> >> -- >> "Catch the Magic of Linux..." >> ------------------------------------------------------------------------ >> Michael Peddemors, President/CEO LinuxMagic Inc. >> Visit us at http://www.linuxmagic.com @linuxmagic >> A Wizard IT Company - For More Info http://www.wizard.ca >> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. >> ------------------------------------------------------------------------ >> 604-682-0300 Beautiful British Columbia, Canada >> >> This email and any electronic data contained are confidential and intended >> solely for the use of the individual or entity to which they are addressed. >> Please note that any views or opinions presented in this email are solely >> those of the author and are not intended to represent those of the company. >> >> _______________________________________________ >> art mailing list >> art@ietf.org >> https://www.ietf.org/mailman/listinfo/art > -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Mon Feb 3 15:11:20 2020 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CEC12006E for ; Mon, 3 Feb 2020 15:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EllFGG2oZTFW for ; Mon, 3 Feb 2020 15:11:17 -0800 (PST) Received: from sdaoden.eu (sdaoden.eu [217.144.132.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 AA9EF120044 for ; Mon, 3 Feb 2020 15:11:17 -0800 (PST) Received: by sdaoden.eu (Postfix, from userid 1000) id 3799A16054; Tue, 4 Feb 2020 00:11:16 +0100 (CET) Date: Tue, 04 Feb 2020 00:11:15 +0100 From: Steffen Nurpmeso To: Michael Peddemors Cc: Eliot Lear , art@ietf.org Message-ID: <20200203231115.WTinN%steffen@sdaoden.eu> In-Reply-To: <298521FA-CC31-4888-99E3-7FE32419679C@cisco.com> References: <55abf67e-6a90-acff-a832-87a168d50522@linuxmagic.com> <298521FA-CC31-4888-99E3-7FE32419679C@cisco.com> Mail-Followup-To: Michael Peddemors , Eliot Lear , art@ietf.org User-Agent: s-nail v14.9.17-43-g63b6e03a OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [art] [FEEDBACK REQUEST] "Birds of a Feather" topic, email security threats X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 23:11:20 -0000 Eliot Lear wrote in <298521FA-CC31-4888-99E3-7FE32419679C@cisco.com>: |> On 3 Feb 2020, at 22:06, Michael Peddemors \ |> wrote: |>=20 |> Call for Feedback: |>=20 |> "Birds of a Feather (BOF)" on email authentication security. ... |> These (our) drafts are related to email security, but as we look \ |> at this serious problem (email compromises), I believe it might be \ |> time to look at the problem in a wider scope, so I am looking at \ |> having a "Birds of a Feather" meeting proposal, that can encompass \ |> a wider discussion on IETF involvement in these issues. |>=20 |> For instance, aside from our IETF drafts on CLIENTID extensions/enhance= m\ |> ents for IMAP/SMTP AUTH, (for those not familiar, references at the \ |> bottom), there are other things that could be addressed in such a \ |> meeting. |>=20 |> * POP/SMTP authentication sent unencrypted over the network |> * AutoDiscovery should NEVER test unencrypted methods |> * Email Clients should deprecate the above |> * Other ideas to address email compromise risks worldwide? ... |> For those not informed, we are looking for a home as well to discuss \ |> our CLIENTID initiatives |>=20 |> https://datatracker.ietf.org/doc/draft-storey-smtp-client-id/?include_t= e\ |> xt=3D1 |> https://tools.ietf.org/html/draft-yu-imap-client-id-03 |IMHO the issue is not one of client identity, but rather preauthorization= \ |versus non-prearranged communication. As to your recommendations below, \ |while there=E2=80=99s nothing wrong with them, even if you implemented th= em, \ |I do not believe that spam would be reduced one iota. | |I would suggest that one delve a bit into per-destination preauthorizatio= n \ |and how that might work from a UX perspective. | |In any case, I=E2=80=99m not sure a formal BoF is called for at this poin= t. \ | Maybe a bar bof. New nuto-configurations (with old software), and old dangling configurations on user boxes, maybe. But new clients, or users which create new accounts manually, or users in an environment with an active administrator, i do not know. I would vote for keeping complexity low, especially when unnecessary. For example the new Unix Alpine version ships with direct XOAUTH2 support, including credential creation and renewal, it needs JSON and HTTP for this, i think. This makes more dependencies etc. etc. I would include that in the protocol, for example, add a renew parameter, and let that cause an additional/extended authentication response with includes the renewed access token. Just as an example, the entire additional logic, or usage of external tools (like mine needs), etc., is gone. Lesser configuration for the user also. And i personally do not think adding yet more to a protocol itself is a right thing to do, especially if the protocol is only payload for a security layer which has the potential to provide desired additional information. For example, EXTERNAL authentication (which however does not seem to be supported well by widely used server/s). Or passing a client certificate as part of the authentication step, if you all enforce XOAUTH2 then this can very well be passed as a base64 token, too. No need for more commands which even possibly require roundtrips, or at least more C/S answer/response interaction. Requiring EXTERNAL has the nice property that the secure transport is implicit. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Mon Feb 3 16:26:59 2020 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0CA1200B5 for ; Mon, 3 Feb 2020 16:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 SvyaFbqww_HT for ; Mon, 3 Feb 2020 16:26:56 -0800 (PST) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 0222F12001A for ; Mon, 3 Feb 2020 16:26:51 -0800 (PST) Received: by mail-vs1-xe2b.google.com with SMTP id n27so10265342vsa.0 for ; Mon, 03 Feb 2020 16:26:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=AXJqlYAXBBpKPZGeeVFkV3YCmJWGqHNVATFeFZTGYWM=; b=mqpVChBsoU9SlAVRSu1bREsvV3Ve1Ce4of0Y/S3SQnBL2cVpp1eXNOLs+GlzRQXqWz t/NB23xS4ajeD6fdGkpxn0a2n582eaQ1cTYAniTr8zoQRhQDH5MCgtGrybSXocxHUmhg QwW/9i+dRTk/tmZgGJsTabKMfs1OrjOl3sFFovsoajZhG4na34KV3oMGor2JXmDU/Lht ee5BzIP8F5c6iKmw9noW4rtkOgSN2v7lDhc+Ti1GDO9h38k8IOSRhzCzlgRJJpMNzoZ+ fAsnjcUrNrLUotc4k1Bhh0K6GIYsRcn/NQo0eLJvbrphohmYwEX78maRONuDYTSqxnbc 3qvQ== 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=AXJqlYAXBBpKPZGeeVFkV3YCmJWGqHNVATFeFZTGYWM=; b=olkZoCFv0n+6QATSGWmwq5lPEI0tJL4joKs0/hkyQAOcZBnvLbwRtFJwExc6QRBAeX yUGwGdSHXu5tFSB0mfXbzVJtzbaEYbocaAKwXWx6ASUzwSjC5rLmmYcLawF9l0EYkHft AGSlRePbhVDGGqu3eX/2SB7CvsHlzOAV3YUIjGD2m/IFJSJKFYvkXwuYx2yBZLtLJp9s ltdgc6rtPIIWP/ppKnry5olLJ2XStieUtv+MlHVxzb1Tn2AVzHmt4/RZXkk1FHaSy0Mv aNd2bbjzAdxTBEs1HBICvsLXHRxrInBK11Qy1q9OILztQ2QTZPq1HZX2p/QAOgJ4zuQw UcXA== X-Gm-Message-State: APjAAAVcAT3BXaN5DcGSc6AKAUA6k7YSJW3XKf91IKiAA0ds0/akanMz +1Om06XsU39pUFVrnJ6q9q7s3OtNSISzYTl5Ad4= X-Google-Smtp-Source: APXvYqzbkhPMDMlObhAp7tEYD5flEwDHdHZMrPULFTYIrrvpHE/C87PvZCbYrIRnEU56hsTDoMmKcNxV2B9LeyT+s7E= X-Received: by 2002:a67:b309:: with SMTP id a9mr15908659vsm.97.1580776010090; Mon, 03 Feb 2020 16:26:50 -0800 (PST) MIME-Version: 1.0 References: <55abf67e-6a90-acff-a832-87a168d50522@linuxmagic.com> <298521FA-CC31-4888-99E3-7FE32419679C@cisco.com> <20200203231115.WTinN%steffen@sdaoden.eu> In-Reply-To: <20200203231115.WTinN%steffen@sdaoden.eu> From: Daniel Migault Date: Mon, 3 Feb 2020 19:26:39 -0500 Message-ID: To: Michael Peddemors , Eliot Lear , art@ietf.org Content-Type: multipart/alternative; boundary="0000000000008d1161059db51891" Archived-At: Subject: Re: [art] [FEEDBACK REQUEST] "Birds of a Feather" topic, email security threats X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 00:26:58 -0000 --0000000000008d1161059db51891 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While the use case is limited to email, I am wondering if the design of an TLS extension would be in scope, so it could be re-used by other applications. Yours, Daniel On Mon, Feb 3, 2020 at 6:11 PM Steffen Nurpmeso wrote: > Eliot Lear wrote in <298521FA-CC31-4888-99E3-7FE32419679C@cisco.com>: > |> On 3 Feb 2020, at 22:06, Michael Peddemors \ > |> wrote: > |> > |> Call for Feedback: > |> > |> "Birds of a Feather (BOF)" on email authentication security. > ... > |> These (our) drafts are related to email security, but as we look \ > |> at this serious problem (email compromises), I believe it might be \ > |> time to look at the problem in a wider scope, so I am looking at \ > |> having a "Birds of a Feather" meeting proposal, that can encompass \ > |> a wider discussion on IETF involvement in these issues. > |> > |> For instance, aside from our IETF drafts on CLIENTID > extensions/enhancem\ > |> ents for IMAP/SMTP AUTH, (for those not familiar, references at the \ > |> bottom), there are other things that could be addressed in such a \ > |> meeting. > |> > |> * POP/SMTP authentication sent unencrypted over the network > |> * AutoDiscovery should NEVER test unencrypted methods > |> * Email Clients should deprecate the above > |> * Other ideas to address email compromise risks worldwide? > ... > |> For those not informed, we are looking for a home as well to discuss = \ > |> our CLIENTID initiatives > |> > |> > https://datatracker.ietf.org/doc/draft-storey-smtp-client-id/?include_te\ > |> xt=3D1 > |> https://tools.ietf.org/html/draft-yu-imap-client-id-03 > > |IMHO the issue is not one of client identity, but rather > preauthorization \ > |versus non-prearranged communication. As to your recommendations below= , > \ > |while there=E2=80=99s nothing wrong with them, even if you implemented = them, \ > |I do not believe that spam would be reduced one iota. > | > |I would suggest that one delve a bit into per-destination > preauthorization \ > |and how that might work from a UX perspective. > | > |In any case, I=E2=80=99m not sure a formal BoF is called for at this po= int. \ > | Maybe a bar bof. > > New nuto-configurations (with old software), and old dangling > configurations on user boxes, maybe. But new clients, or users > which create new accounts manually, or users in an environment > with an active administrator, i do not know. > > I would vote for keeping complexity low, especially when > unnecessary. For example the new Unix Alpine version ships with > direct XOAUTH2 support, including credential creation and renewal, > it needs JSON and HTTP for this, i think. This makes more > dependencies etc. etc. I would include that in the protocol, for > example, add a renew parameter, and let that cause an > additional/extended authentication response with includes the > renewed access token. Just as an example, the entire additional > logic, or usage of external tools (like mine needs), etc., is > gone. Lesser configuration for the user also. > > And i personally do not think adding yet more to a protocol itself > is a right thing to do, especially if the protocol is only payload > for a security layer which has the potential to provide desired > additional information. For example, EXTERNAL authentication > (which however does not seem to be supported well by widely used > server/s). Or passing a client certificate as part of the > authentication step, if you all enforce XOAUTH2 then this can very > well be passed as a base64 token, too. No need for more commands > which even possibly require roundtrips, or at least more C/S > answer/response interaction. > Requiring EXTERNAL has the nice property that the secure transport > is implicit. > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > --=20 Daniel Migault Ericsson --0000000000008d1161059db51891 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While the use case is limited to email, I am wonderin= g if the design of an TLS extension would be in scope, so it could be re-us= ed by other applications.=C2=A0 =C2=A0=C2=A0

Y= ours,=C2=A0
Daniel

On Mon, Feb 3, 2020 at 6:11 PM Steffen Nurpmeso = <steffen@sdaoden.eu> wrote:=
Eliot Lear wrot= e in <298521FA-CC31-4888-99E3-7FE32419679C@cisco.com>: =C2=A0|> On 3 Feb 2020, at 22:06, Michael Peddemors <michael@linuxmagic.com> = \
=C2=A0|> wrote:
=C2=A0|>
=C2=A0|> Call for Feedback:
=C2=A0|>
=C2=A0|> "Birds of a Feather (BOF)" on email authentication se= curity.
=C2=A0...
=C2=A0|> These (our) drafts are related to email security, but as we loo= k \
=C2=A0|> at this serious problem (email compromises), I believe it might= be \
=C2=A0|> time to look at the problem in a wider scope, so I am looking a= t \
=C2=A0|> having a "Birds of a Feather" meeting proposal, that = can encompass \
=C2=A0|> a wider discussion on IETF involvement in these issues.
=C2=A0|>
=C2=A0|> For instance, aside from our IETF drafts on CLIENTID extensions= /enhancem\
=C2=A0|> ents for IMAP/SMTP AUTH, (for those not familiar, references at= the \
=C2=A0|> bottom), there are other things that could be addressed in such= a \
=C2=A0|> meeting.
=C2=A0|>
=C2=A0|> * POP/SMTP authentication sent unencrypted over the network
=C2=A0|> * AutoDiscovery should NEVER test unencrypted methods
=C2=A0|> * Email Clients should deprecate the above
=C2=A0|> * Other ideas to address email compromise risks worldwide?
=C2=A0...
=C2=A0|> For those not informed, we are looking for a home as well to di= scuss \
=C2=A0|> our CLIENTID initiatives
=C2=A0|>
=C2=A0|> https://datat= racker.ietf.org/doc/draft-storey-smtp-client-id/?include_te\
=C2=A0|> xt=3D1
=C2=A0|> https://tools.ietf.org/html/draft-= yu-imap-client-id-03

=C2=A0|IMHO the issue is not one of client identity, but rather preauthoriz= ation \
=C2=A0|versus non-prearranged communication.=C2=A0 As to your recommendatio= ns below, \
=C2=A0|while there=E2=80=99s nothing wrong with them, even if you implement= ed them, \
=C2=A0|I do not believe that spam would be reduced one iota.
=C2=A0|
=C2=A0|I would suggest that one delve a bit into per-destination preauthori= zation \
=C2=A0|and how that might work from a UX perspective.
=C2=A0|
=C2=A0|In any case, I=E2=80=99m not sure a formal BoF is called for at this= point. \
=C2=A0| Maybe a bar bof.

New nuto-configurations (with old software), and old dangling
configurations on user boxes, maybe.=C2=A0 But new clients, or users
which create new accounts manually, or users in an environment
with an active administrator, i do not know.

I would vote for keeping complexity low, especially when
unnecessary.=C2=A0 For example the new Unix Alpine version ships with
direct XOAUTH2 support, including credential creation and renewal,
it needs JSON and HTTP for this, i think.=C2=A0 This makes more
dependencies etc. etc.=C2=A0 I would include that in the protocol, for
example, add a renew parameter, and let that cause an
additional/extended authentication response with includes the
renewed access token.=C2=A0 Just as an example, the entire additional
logic, or usage of external tools (like mine needs), etc., is
gone.=C2=A0 Lesser configuration for the user also.

And i personally do not think adding yet more to a protocol itself
is a right thing to do, especially if the protocol is only payload
for a security layer which has the potential to provide desired
additional information.=C2=A0 For example, EXTERNAL authentication
(which however does not seem to be supported well by widely used
server/s).=C2=A0 Or passing a client certificate as part of the
authentication step, if you all enforce XOAUTH2 then this can very
well be passed as a base64 token, too.=C2=A0 No need for more commands
which even possibly require roundtrips, or at least more C/S
answer/response interaction.
Requiring EXTERNAL has the nice property that the secure transport
is implicit.

--steffen
|
|Der Kragenbaer,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The= moon bear,
|der holt sich munter=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0he cheerfully= and one by one
|einen nach dem anderen runter=C2=A0 wa.ks himself off
|(By Robert Gernhardt)

_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art


--
Daniel Migault
Ericsson
--0000000000008d1161059db51891-- From nobody Mon Feb 3 18:23:58 2020 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1427812004A for ; Mon, 3 Feb 2020 18:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 RSq9u7PlZkMe for ; Mon, 3 Feb 2020 18:23:54 -0800 (PST) Received: from mail-vs1-xe43.google.com (mail-vs1-xe43.google.com [IPv6:2607:f8b0:4864:20::e43]) (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 239A412001A for ; Mon, 3 Feb 2020 18:23:28 -0800 (PST) Received: by mail-vs1-xe43.google.com with SMTP id a2so10394216vso.3 for ; Mon, 03 Feb 2020 18:23:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GZmEQGBJ6FKkdc6Gxi5sZL6WK8/kx2PYvFJoNZGUX/0=; b=pazVz9omMJMspkzE0JwsrUFu0Sk1EI0W36Rf4ycmUHt+vxHRaRv2W9as12+F0yO2uE qOwWqRTFQrV2Wecv9gGSSuU3gD+CAdyUCJ1YqQjCrVoNFvobzj4KTcVg33v/vKuSUed+ UlyZnB7ALVT+3472P41KNH6k8+g+FaZBQP83wJKON+2Wl5VmVlJ+SLPUwn8JVhUdzZiW 36qQm3bhHx2aU6rB2oNMiG8/lAZXYIzDKz+uT6TkNEioF60xE/TT3B//eB6WCUvuQYtz SY8uyDZqXevmiW4JD/7exd9lkST1nMgESVwhZWAFPMA6wVES1etstLprPnoGXt2ezcG3 zwtw== 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=GZmEQGBJ6FKkdc6Gxi5sZL6WK8/kx2PYvFJoNZGUX/0=; b=jXQMRyJwbY3KcjIY37NF4J/VHybt7pHmMCGBJXugvyEazfUkeiBtDf9LJ6VO2W2J5W E48lDLecVSlT0e9Jj2I8VIdyq7cpAyc1nkLaqXe50vC4nGigqs/1mvKQvREtAgw2abvR bdhHhFWWhQYX02ZFd2Bsx5XMB5kUEj8CaF5hsI6ywnwEqeuuyh96f2+6UCrz7yEujbGn mE4t0kvQwK8BR0fdfOQakzz1RKqIiUqUKLwEPw2too14pte/ic5qKG5yag17ndQnavfx p6qvbtcxG4P5FQM1PH3lRGCO3rI+3yiMBRCBTp55lXMXpiNqGFUrfImgG153e3JUNhQo 8+kw== X-Gm-Message-State: APjAAAXhkcmM1Av4YsH5CZA5srwvJSmwU7LwvoLPyUQ26Yb3KBGLj2mM sPBNih31PxxMQXzZ3pgz9qRea7sEHa+vlSGqn1zo X-Google-Smtp-Source: APXvYqyLPY3/X7etY429Q5pORjaE1/ird1XAtSUbGS9WhjLOAj4yYMA2JGNupGrgaJdMDf69b11KW56RMiPWTlXTt+8= X-Received: by 2002:a05:6102:22f0:: with SMTP id b16mr15899167vsh.238.1580783006716; Mon, 03 Feb 2020 18:23:26 -0800 (PST) MIME-Version: 1.0 References: <55abf67e-6a90-acff-a832-87a168d50522@linuxmagic.com> <298521FA-CC31-4888-99E3-7FE32419679C@cisco.com> <20200203231115.WTinN%steffen@sdaoden.eu> In-Reply-To: From: Brandon Long Date: Mon, 3 Feb 2020 18:23:14 -0800 Message-ID: To: Daniel Migault Cc: Michael Peddemors , Eliot Lear , art@ietf.org Content-Type: multipart/alternative; boundary="00000000000095a875059db6b9d4" Archived-At: Subject: Re: [art] [FEEDBACK REQUEST] "Birds of a Feather" topic, email security threats X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 02:23:57 -0000 --00000000000095a875059db6b9d4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I mean, if it's part of auth, shouldn't it be in SASL? Michael and I have had that argument before, but in any case, where isn't really the question so much as whether it's useful, the details can be worked out. It has the benefit of simplicity vs things like OAUTHBEARER, but is that really the barrier here? Brandon On Mon, Feb 3, 2020 at 4:27 PM Daniel Migault wrote: > While the use case is limited to email, I am wondering if the design of a= n > TLS extension would be in scope, so it could be re-used by other > applications. > > Yours, > Daniel > > On Mon, Feb 3, 2020 at 6:11 PM Steffen Nurpmeso > wrote: > >> Eliot Lear wrote in <298521FA-CC31-4888-99E3-7FE32419679C@cisco.com>: >> |> On 3 Feb 2020, at 22:06, Michael Peddemors = \ >> |> wrote: >> |> >> |> Call for Feedback: >> |> >> |> "Birds of a Feather (BOF)" on email authentication security. >> ... >> |> These (our) drafts are related to email security, but as we look \ >> |> at this serious problem (email compromises), I believe it might be \ >> |> time to look at the problem in a wider scope, so I am looking at \ >> |> having a "Birds of a Feather" meeting proposal, that can encompass \ >> |> a wider discussion on IETF involvement in these issues. >> |> >> |> For instance, aside from our IETF drafts on CLIENTID >> extensions/enhancem\ >> |> ents for IMAP/SMTP AUTH, (for those not familiar, references at the = \ >> |> bottom), there are other things that could be addressed in such a \ >> |> meeting. >> |> >> |> * POP/SMTP authentication sent unencrypted over the network >> |> * AutoDiscovery should NEVER test unencrypted methods >> |> * Email Clients should deprecate the above >> |> * Other ideas to address email compromise risks worldwide? >> ... >> |> For those not informed, we are looking for a home as well to discuss= \ >> |> our CLIENTID initiatives >> |> >> |> >> https://datatracker.ietf.org/doc/draft-storey-smtp-client-id/?include_te= \ >> |> xt=3D1 >> |> https://tools.ietf.org/html/draft-yu-imap-client-id-03 >> >> |IMHO the issue is not one of client identity, but rather >> preauthorization \ >> |versus non-prearranged communication. As to your recommendations >> below, \ >> |while there=E2=80=99s nothing wrong with them, even if you implemented= them, \ >> |I do not believe that spam would be reduced one iota. >> | >> |I would suggest that one delve a bit into per-destination >> preauthorization \ >> |and how that might work from a UX perspective. >> | >> |In any case, I=E2=80=99m not sure a formal BoF is called for at this p= oint. \ >> | Maybe a bar bof. >> >> New nuto-configurations (with old software), and old dangling >> configurations on user boxes, maybe. But new clients, or users >> which create new accounts manually, or users in an environment >> with an active administrator, i do not know. >> >> I would vote for keeping complexity low, especially when >> unnecessary. For example the new Unix Alpine version ships with >> direct XOAUTH2 support, including credential creation and renewal, >> it needs JSON and HTTP for this, i think. This makes more >> dependencies etc. etc. I would include that in the protocol, for >> example, add a renew parameter, and let that cause an >> additional/extended authentication response with includes the >> renewed access token. Just as an example, the entire additional >> logic, or usage of external tools (like mine needs), etc., is >> gone. Lesser configuration for the user also. >> >> And i personally do not think adding yet more to a protocol itself >> is a right thing to do, especially if the protocol is only payload >> for a security layer which has the potential to provide desired >> additional information. For example, EXTERNAL authentication >> (which however does not seem to be supported well by widely used >> server/s). Or passing a client certificate as part of the >> authentication step, if you all enforce XOAUTH2 then this can very >> well be passed as a base64 token, too. No need for more commands >> which even possibly require roundtrips, or at least more C/S >> answer/response interaction. >> Requiring EXTERNAL has the nice property that the secure transport >> is implicit. >> >> --steffen >> | >> |Der Kragenbaer, The moon bear, >> |der holt sich munter he cheerfully and one by one >> |einen nach dem anderen runter wa.ks himself off >> |(By Robert Gernhardt) >> >> _______________________________________________ >> art mailing list >> art@ietf.org >> https://www.ietf.org/mailman/listinfo/art >> > > > -- > Daniel Migault > Ericsson > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > --00000000000095a875059db6b9d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I mean, if it's part of auth, shouldn't it be in S= ASL?=C2=A0 Michael and I have had that argument before, but in any case, wh= ere isn't really the question so much as whether it's useful, the d= etails can be worked out.

It has the benefit of simplicity vs things= like OAUTHBEARER, but is that really the barrier here?

Brandon
On Mo= n, Feb 3, 2020 at 4:27 PM Daniel Migault <mglt.ietf@gmail.com> wrote:
While the use case is lim= ited to email, I am wondering if the design of an TLS extension would be in= scope, so it could be re-used by other applications.=C2=A0 =C2=A0=C2=A0

Yours,=C2=A0
Daniel

On Mon, Feb 3, 2020 = at 6:11 PM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
Eliot Lear wrote in <298521FA-= CC31-4888-99E3-7FE32419679C@cisco.com>:
=C2=A0|> On 3 Feb 2020, at 22:06, Michael Peddemors <michael@linuxmagic.com> = \
=C2=A0|> wrote:
=C2=A0|>
=C2=A0|> Call for Feedback:
=C2=A0|>
=C2=A0|> "Birds of a Feather (BOF)" on email authentication se= curity.
=C2=A0...
=C2=A0|> These (our) drafts are related to email security, but as we loo= k \
=C2=A0|> at this serious problem (email compromises), I believe it might= be \
=C2=A0|> time to look at the problem in a wider scope, so I am looking a= t \
=C2=A0|> having a "Birds of a Feather" meeting proposal, that = can encompass \
=C2=A0|> a wider discussion on IETF involvement in these issues.
=C2=A0|>
=C2=A0|> For instance, aside from our IETF drafts on CLIENTID extensions= /enhancem\
=C2=A0|> ents for IMAP/SMTP AUTH, (for those not familiar, references at= the \
=C2=A0|> bottom), there are other things that could be addressed in such= a \
=C2=A0|> meeting.
=C2=A0|>
=C2=A0|> * POP/SMTP authentication sent unencrypted over the network
=C2=A0|> * AutoDiscovery should NEVER test unencrypted methods
=C2=A0|> * Email Clients should deprecate the above
=C2=A0|> * Other ideas to address email compromise risks worldwide?
=C2=A0...
=C2=A0|> For those not informed, we are looking for a home as well to di= scuss \
=C2=A0|> our CLIENTID initiatives
=C2=A0|>
=C2=A0|> https://datat= racker.ietf.org/doc/draft-storey-smtp-client-id/?include_te\
=C2=A0|> xt=3D1
=C2=A0|> https://tools.ietf.org/html/draft-= yu-imap-client-id-03

=C2=A0|IMHO the issue is not one of client identity, but rather preauthoriz= ation \
=C2=A0|versus non-prearranged communication.=C2=A0 As to your recommendatio= ns below, \
=C2=A0|while there=E2=80=99s nothing wrong with them, even if you implement= ed them, \
=C2=A0|I do not believe that spam would be reduced one iota.
=C2=A0|
=C2=A0|I would suggest that one delve a bit into per-destination preauthori= zation \
=C2=A0|and how that might work from a UX perspective.
=C2=A0|
=C2=A0|In any case, I=E2=80=99m not sure a formal BoF is called for at this= point. \
=C2=A0| Maybe a bar bof.

New nuto-configurations (with old software), and old dangling
configurations on user boxes, maybe.=C2=A0 But new clients, or users
which create new accounts manually, or users in an environment
with an active administrator, i do not know.

I would vote for keeping complexity low, especially when
unnecessary.=C2=A0 For example the new Unix Alpine version ships with
direct XOAUTH2 support, including credential creation and renewal,
it needs JSON and HTTP for this, i think.=C2=A0 This makes more
dependencies etc. etc.=C2=A0 I would include that in the protocol, for
example, add a renew parameter, and let that cause an
additional/extended authentication response with includes the
renewed access token.=C2=A0 Just as an example, the entire additional
logic, or usage of external tools (like mine needs), etc., is
gone.=C2=A0 Lesser configuration for the user also.

And i personally do not think adding yet more to a protocol itself
is a right thing to do, especially if the protocol is only payload
for a security layer which has the potential to provide desired
additional information.=C2=A0 For example, EXTERNAL authentication
(which however does not seem to be supported well by widely used
server/s).=C2=A0 Or passing a client certificate as part of the
authentication step, if you all enforce XOAUTH2 then this can very
well be passed as a base64 token, too.=C2=A0 No need for more commands
which even possibly require roundtrips, or at least more C/S
answer/response interaction.
Requiring EXTERNAL has the nice property that the secure transport
is implicit.

--steffen
|
|Der Kragenbaer,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The= moon bear,
|der holt sich munter=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0he cheerfully= and one by one
|einen nach dem anderen runter=C2=A0 wa.ks himself off
|(By Robert Gernhardt)

_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art


--
Daniel Migault
Ericsson
_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art
--00000000000095a875059db6b9d4-- From nobody Tue Feb 4 06:42:27 2020 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1213E1200CD for ; Tue, 4 Feb 2020 06:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=VscxLaRP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iGUWnArV 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 EeeJ9UlOk0Wz for ; Tue, 4 Feb 2020 06:42:23 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E09120105 for ; Tue, 4 Feb 2020 06:42:23 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id D24D321B5A; Tue, 4 Feb 2020 09:42:22 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Tue, 04 Feb 2020 09:42:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=80AlpUBu6DQYMlAidORqabpniY/8yF5 /J+eMcO5QWXs=; b=VscxLaRPfgok7vvhpw3TZDyrjrgp8Y5kXPcBm/CtN5EaRxF 1hPhx00iMII2jmfTyuvOcEzbAdl5PeR6TMoupSCwx+HcIBxNUR+uqWNUUqTNZTSS c/V5h+hDJcZGoAVJ7NO7WpLiw8v7iXyztSha2VrrAHFAMsKNQ0rQJ7eg3eeQtO2V I7uib4/cc5SpfqoWStjRKyglymb0K1F2kaxU8u5pOn6pnQRZH0IdSnUor1kDVDGI UyoqPYm+pd/aXPsUyXweMj3XK7OZAHXUE0zY9gDb171qXlg0L5ezM2L5Eulmpdlz tBrXpe6E3CCp+Qdc+Z3GOKtihZiVjXI8uS0A3Pw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm1; bh=80AlpU Bu6DQYMlAidORqabpniY/8yF5/J+eMcO5QWXs=; b=iGUWnArVb/YqBkT/sU97Oo Fe10aXXT/XRzkFcqUtxIX+LacXO8nNXo+LVepxrlqEnKXujapg/aPoaGvqdb6rLa h+zapozt3I6A2HzCN8ilChMHsVcJVTxQAgdempogS9RZHdXHFFhdJQuGzVLExGIb mJIHWYbgB8TGc2SAfllHOcSpdwfSH7yaRzzJtdw5hH/13kScLT7zBij9WguhdSEI gg6zp7E/KB4e5YwzPVTY1gve6TfsmJi91E7kvoXIbHwlLtz8X4QospSkSzz3qKbg U2g0n4SX8DBNNb/LoBhnygi6DFZ9qxpO+IHrRSpQj/j0Npq/hPRel4wS8ESjEnYA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrgeelgdeikecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegr rghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 994E0660065; Tue, 4 Feb 2020 09:42:22 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: <2746917c-4049-44fc-abab-97dd9ff2abd5@www.fastmail.com> In-Reply-To: References: <55abf67e-6a90-acff-a832-87a168d50522@linuxmagic.com> <298521FA-CC31-4888-99E3-7FE32419679C@cisco.com> <20200203231115.WTinN%steffen@sdaoden.eu> Date: Tue, 04 Feb 2020 14:41:52 +0000 From: "Alexey Melnikov" To: "Brandon Long" Cc: "Michael Peddemors" , art@ietf.org Content-Type: multipart/alternative; boundary=6b201cf29e284d9696e8f5506f6e4e6b Archived-At: Subject: [art] =?utf-8?b?PT9VVEYtOD9RP1JlOl9fW0ZFRURCQUNLX1JFUVVFU1RdXyJC?= =?utf-8?b?aXJkc19vZl9hX0ZlYXRoZXIiX3RvcGljLCBfZW1haWw/PSAgc2VjdXJpdHkg?= =?utf-8?q?threats?= X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 14:42:25 -0000 --6b201cf29e284d9696e8f5506f6e4e6b Content-Type: text/plain On just this one point: On Tue, Feb 4, 2020, at 2:23 AM, Brandon Long wrote: > I mean, if it's part of auth, shouldn't it be in SASL? Michael and I have had that argument before, but in any case, where isn't really the question so much as whether it's useful, the details can be worked out. I do think that if this needs solving that it should be solved at SASL level (because it is cross protocol). --6b201cf29e284d9696e8f5506f6e4e6b Content-Type: text/html
On just this one point:

On Tue, Feb 4, 2020, at 2:23 AM, Brandon Long wrote:
I mean, if it's part of auth, shouldn't it be in SASL?  Michael and I have had that argument before, but in any case, where isn't really the question so much as whether it's useful, the details can be worked out.

I do think that if this needs solving that it should be solved at SASL level (because it is cross protocol).

--6b201cf29e284d9696e8f5506f6e4e6b-- From nobody Tue Feb 4 07:04:21 2020 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83532120110 for ; Tue, 4 Feb 2020 07:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.736 X-Spam-Level: X-Spam-Status: No, score=0.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SBL_CSS=3.335, 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 c2VIgADKl9vh for ; Tue, 4 Feb 2020 07:04:14 -0800 (PST) Received: from fe1.cityemail.com (mail-ob1.cityemail.com [104.128.152.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6165D120105 for ; Tue, 4 Feb 2020 07:04:14 -0800 (PST) Received: (qmail 9453 invoked from network); 4 Feb 2020 15:04:13 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe1.cityemail.com with (AES128-SHA encrypted) SMTP (9a8d41b8-475f-11ea-adcc-7f986cb5ac2d); Tue, 04 Feb 2020 07:04:13 -0800 To: Alexey Melnikov , Brandon Long Cc: art@ietf.org References: <55abf67e-6a90-acff-a832-87a168d50522@linuxmagic.com> <298521FA-CC31-4888-99E3-7FE32419679C@cisco.com> <20200203231115.WTinN%steffen@sdaoden.eu> <2746917c-4049-44fc-abab-97dd9ff2abd5@www.fastmail.com> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: Date: Tue, 4 Feb 2020 07:04:12 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <2746917c-4049-44fc-abab-97dd9ff2abd5@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: 9a8d41b8-475f-11ea-adcc-7f986cb5ac2d X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: Re: [art] [FEEDBACK REQUEST] "Birds of a Feather" topic, email security threats X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 15:04:17 -0000 On 2020-02-04 6:41 a.m., Alexey Melnikov wrote: > On just this one point: > > On Tue, Feb 4, 2020, at 2:23 AM, Brandon Long wrote: >> I mean, if it's part of auth, shouldn't it be in SASL?  Michael and I >> have had that argument before, but in any case, where isn't really the >> question so much as whether it's useful, the details can be worked out. > > I do think that if this needs solving that it should be solved at SASL > level (because it is cross protocol). > And that's why a BOF would be a good idea ;) We strongly feel that CLIENTID is more than a component of SASL, as a 'trust factor', an 'access control token', and as an element of 'two factor'. Should an implementor choose to use CLIENTID and pass it on to the SASL, perfectly fine if they want to do logic there, but this makes it available to all forms of authentication. But we can talk CLIENTID at the BOF, for now looking to see overall interest in the topic of email security, and what should be included. -- Michael -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Tue Feb 4 10:50:34 2020 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4861201A3 for ; Tue, 4 Feb 2020 10:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 ERGgB9QaIogQ for ; Tue, 4 Feb 2020 10:50:27 -0800 (PST) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 0EB5F12018B for ; Tue, 4 Feb 2020 10:50:27 -0800 (PST) Received: by mail-vk1-xa36.google.com with SMTP id w67so5486657vkf.1 for ; Tue, 04 Feb 2020 10:50:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u7GxjXT0QlrzGiWWjDay6TO90Q2izaPGtY4fwjznf/Q=; b=ps384wrrOLUyzl6W4krQdmcSNauty8ByGjXpDO6ZhfDKCzE8t7qMhb+YTEvo4Gh0AT azODgLwnVI8WbaudQAQVShqg5w6hGmO75SLPZwBCk9j4rO+yxauBI4UcSOgpCKNTZppA 5J6plUCv9kf25C0NT2DKjsTcMbINsXaCIjfdzswAlsGA9JVCAq2hj5lfrGqywDNymJf2 C/wuZFx2bJ2X3/YD0MrJE0sIJrk+09AgLvX0X2vlYbihXhjDPQ1j39hq5Iep2olbziAE o3LU9Ajmsj5lWETbDTImi8YiF8Ag9HtnWLA54Xgm8aoMTFraw8x4g60940tcJ7TOSoYI hUyA== 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=u7GxjXT0QlrzGiWWjDay6TO90Q2izaPGtY4fwjznf/Q=; b=gde5nCJJEGguyaEuyIVIk8MaQGNczeXG+pNOPA1EmU8NMf3m/Xb1xhdY0ur9rSDBrC 7UxMx0r8fMFzbmMkiNeuj5WUCFGRvyv8oSpOtC9ArVJ93AlLEOOVE9f4KrvJD0fsj53a y4g4Wrlha+gDQUGmjDCG5K0mfnxOOMrFSCyBZhGrNe24PZLFqWfv9Qi4t+JSDUJlSold 9PtPp7AKVKCMBmh/xa136nV/f4Cd/yAfNKm19Hxpq3fzs5n9mrlQpYlOCfFL0NWG4VnB VqpH+zSG/5UThp+sv7G1XZYkXC1W8TvQftR4hVWdeYxyDumfkWRaITaq1IN48w15v/3O 4ZsQ== X-Gm-Message-State: APjAAAWinLBftxnU6UeJT1LTZK9QFfo/bvkh3dT6OoXEskSr4xs+LPsD kFSBSyrLYKlnrvULYBRtioC/3B86SikZ8eONcFs= X-Google-Smtp-Source: APXvYqwXfdhlLPWtZrNnY9OcwaNavkTluyve/3fa6uDMp6OECiwdFSIe5JhyNFx2BoAAdGBJUsEa1DXJ1lCA3Hqo3AU= X-Received: by 2002:a1f:add3:: with SMTP id w202mr18153078vke.30.1580842225985; Tue, 04 Feb 2020 10:50:25 -0800 (PST) MIME-Version: 1.0 References: <55abf67e-6a90-acff-a832-87a168d50522@linuxmagic.com> <298521FA-CC31-4888-99E3-7FE32419679C@cisco.com> <20200203231115.WTinN%steffen@sdaoden.eu> In-Reply-To: From: Daniel Migault Date: Tue, 4 Feb 2020 13:50:16 -0500 Message-ID: To: Brandon Long Cc: Michael Peddemors , Eliot Lear , art@ietf.org Content-Type: multipart/alternative; boundary="000000000000536d66059dc48330" Archived-At: Subject: Re: [art] [FEEDBACK REQUEST] "Birds of a Feather" topic, email security threats X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 18:50:33 -0000 --000000000000536d66059dc48330 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I agree that my question was whether this could be useful to rely on the lower layer (e.g. TLS) . I see two types of mechanisms: 1. Those that require interactions between the application and the TLS layer, typically if we ask to type the password. 2. Those that can completely delegated to TLS, and just enabled them is sufficient. I like (1.) but my impression is that this has not been so successful so far. So I am wondering if that is a path we should consider, and at least try to make it successful. I am happy to hear what people think. For (2), I am assuming that interactions between the application and the TL= S layer may add complexity, which slows adoption of these mechanisms. As a result, it might be good to explore also extensions that provides limited capabilities. As 2FA was mentioned, mechanisms like identity pinning [1] is one example of a specific extension that could address partially some needs without requiring interaction between the application and the TLS layer. I might be biased though. Yours, Daniel [1] https://www.rfc-editor.org/rfc/rfc8672.html On Mon, Feb 3, 2020 at 9:23 PM Brandon Long wrote: > I mean, if it's part of auth, shouldn't it be in SASL? Michael and I hav= e > had that argument before, but in any case, where isn't really the questio= n > so much as whether it's useful, the details can be worked out. > > It has the benefit of simplicity vs things like OAUTHBEARER, but is that > really the barrier here? > > Brandon > > On Mon, Feb 3, 2020 at 4:27 PM Daniel Migault wrote= : > >> While the use case is limited to email, I am wondering if the design of >> an TLS extension would be in scope, so it could be re-used by other >> applications. >> >> Yours, >> Daniel >> >> On Mon, Feb 3, 2020 at 6:11 PM Steffen Nurpmeso >> wrote: >> >>> Eliot Lear wrote in <298521FA-CC31-4888-99E3-7FE32419679C@cisco.com>: >>> |> On 3 Feb 2020, at 22:06, Michael Peddemors >>> \ >>> |> wrote: >>> |> >>> |> Call for Feedback: >>> |> >>> |> "Birds of a Feather (BOF)" on email authentication security. >>> ... >>> |> These (our) drafts are related to email security, but as we look \ >>> |> at this serious problem (email compromises), I believe it might be = \ >>> |> time to look at the problem in a wider scope, so I am looking at \ >>> |> having a "Birds of a Feather" meeting proposal, that can encompass = \ >>> |> a wider discussion on IETF involvement in these issues. >>> |> >>> |> For instance, aside from our IETF drafts on CLIENTID >>> extensions/enhancem\ >>> |> ents for IMAP/SMTP AUTH, (for those not familiar, references at the= \ >>> |> bottom), there are other things that could be addressed in such a \ >>> |> meeting. >>> |> >>> |> * POP/SMTP authentication sent unencrypted over the network >>> |> * AutoDiscovery should NEVER test unencrypted methods >>> |> * Email Clients should deprecate the above >>> |> * Other ideas to address email compromise risks worldwide? >>> ... >>> |> For those not informed, we are looking for a home as well to discus= s >>> \ >>> |> our CLIENTID initiatives >>> |> >>> |> >>> https://datatracker.ietf.org/doc/draft-storey-smtp-client-id/?include_t= e\ >>> |> xt=3D1 >>> |> https://tools.ietf.org/html/draft-yu-imap-client-id-03 >>> >>> |IMHO the issue is not one of client identity, but rather >>> preauthorization \ >>> |versus non-prearranged communication. As to your recommendations >>> below, \ >>> |while there=E2=80=99s nothing wrong with them, even if you implemente= d them, \ >>> |I do not believe that spam would be reduced one iota. >>> | >>> |I would suggest that one delve a bit into per-destination >>> preauthorization \ >>> |and how that might work from a UX perspective. >>> | >>> |In any case, I=E2=80=99m not sure a formal BoF is called for at this = point. \ >>> | Maybe a bar bof. >>> >>> New nuto-configurations (with old software), and old dangling >>> configurations on user boxes, maybe. But new clients, or users >>> which create new accounts manually, or users in an environment >>> with an active administrator, i do not know. >>> >>> I would vote for keeping complexity low, especially when >>> unnecessary. For example the new Unix Alpine version ships with >>> direct XOAUTH2 support, including credential creation and renewal, >>> it needs JSON and HTTP for this, i think. This makes more >>> dependencies etc. etc. I would include that in the protocol, for >>> example, add a renew parameter, and let that cause an >>> additional/extended authentication response with includes the >>> renewed access token. Just as an example, the entire additional >>> logic, or usage of external tools (like mine needs), etc., is >>> gone. Lesser configuration for the user also. >>> >>> And i personally do not think adding yet more to a protocol itself >>> is a right thing to do, especially if the protocol is only payload >>> for a security layer which has the potential to provide desired >>> additional information. For example, EXTERNAL authentication >>> (which however does not seem to be supported well by widely used >>> server/s). Or passing a client certificate as part of the >>> authentication step, if you all enforce XOAUTH2 then this can very >>> well be passed as a base64 token, too. No need for more commands >>> which even possibly require roundtrips, or at least more C/S >>> answer/response interaction. >>> Requiring EXTERNAL has the nice property that the secure transport >>> is implicit. >>> >>> --steffen >>> | >>> |Der Kragenbaer, The moon bear, >>> |der holt sich munter he cheerfully and one by one >>> |einen nach dem anderen runter wa.ks himself off >>> |(By Robert Gernhardt) >>> >>> _______________________________________________ >>> art mailing list >>> art@ietf.org >>> https://www.ietf.org/mailman/listinfo/art >>> >> >> >> -- >> Daniel Migault >> Ericsson >> _______________________________________________ >> art mailing list >> art@ietf.org >> https://www.ietf.org/mailman/listinfo/art >> > --=20 Daniel Migault Ericsson --000000000000536d66059dc48330 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

I agree that my question was = whether this could be useful to rely on the lower layer (e.g. TLS) . I see two type= s of mechanisms:
1. Those that require interactions between the a= pplication and the TLS layer, typically if we ask to type the password.=C2=A0
2. Those that can completely delegated to TLS, and just enabled them is sufficient= .

I like (1.) but my impression is that this has n= ot been so successful so far. So I am wondering if that is a path we should= consider, and at least try to make it successful. I am happy to hear what = people think.=C2=A0

For (2), I am assuming that in= teractions between the application and the TLS layer may add complexity, which slows = adoption of these mechanisms. As a result,=C2=A0it might be good to explore= also extensions that provides limited capabilities. As 2FA was mentioned, = mechanisms like identity pinning [1] is one example of a specific extension= that could address partially some needs without requiring interaction betw= een the application and the TLS layer. I might be biased though.=C2=A0 =C2=A0 =C2=A0<= /div>

Yours,=C2=A0
Daniel


=C2=A0

On Mon, Feb 3, 2020 = at 9:23 PM Brandon Long <blong@googl= e.com> wrote:
I mean, if it's part of auth, shouldn't it be= in SASL?=C2=A0 Michael and I have had that argument before, but in any cas= e, where isn't really the question so much as whether it's useful, = the details can be worked out.

It has the benefit of simplicity vs t= hings like OAUTHBEARER, but is that really the barrier here?

Brandon=

= On Mon, Feb 3, 2020 at 4:27 PM Daniel Migault <mglt.ietf@gmail.com> wrote:
Wh= ile the use case is limited to email, I am wondering if the design of an TL= S extension would be in scope, so it could be re-used by other applications= .=C2=A0 =C2=A0=C2=A0

Yours,=C2=A0
Daniel

On Mon, Feb 3, 2020 at 6:11 PM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
Eliot Lear wrote in &= lt;298521FA-CC31-4888-99E3-7FE32419679C@cisco.com>:
=C2=A0|> On 3 Feb 2020, at 22:06, Michael Peddemors <michael@linuxmagic.com> = \
=C2=A0|> wrote:
=C2=A0|>
=C2=A0|> Call for Feedback:
=C2=A0|>
=C2=A0|> "Birds of a Feather (BOF)" on email authentication se= curity.
=C2=A0...
=C2=A0|> These (our) drafts are related to email security, but as we loo= k \
=C2=A0|> at this serious problem (email compromises), I believe it might= be \
=C2=A0|> time to look at the problem in a wider scope, so I am looking a= t \
=C2=A0|> having a "Birds of a Feather" meeting proposal, that = can encompass \
=C2=A0|> a wider discussion on IETF involvement in these issues.
=C2=A0|>
=C2=A0|> For instance, aside from our IETF drafts on CLIENTID extensions= /enhancem\
=C2=A0|> ents for IMAP/SMTP AUTH, (for those not familiar, references at= the \
=C2=A0|> bottom), there are other things that could be addressed in such= a \
=C2=A0|> meeting.
=C2=A0|>
=C2=A0|> * POP/SMTP authentication sent unencrypted over the network
=C2=A0|> * AutoDiscovery should NEVER test unencrypted methods
=C2=A0|> * Email Clients should deprecate the above
=C2=A0|> * Other ideas to address email compromise risks worldwide?
=C2=A0...
=C2=A0|> For those not informed, we are looking for a home as well to di= scuss \
=C2=A0|> our CLIENTID initiatives
=C2=A0|>
=C2=A0|> https://datat= racker.ietf.org/doc/draft-storey-smtp-client-id/?include_te\
=C2=A0|> xt=3D1
=C2=A0|> https://tools.ietf.org/html/draft-= yu-imap-client-id-03

=C2=A0|IMHO the issue is not one of client identity, but rather preauthoriz= ation \
=C2=A0|versus non-prearranged communication.=C2=A0 As to your recommendatio= ns below, \
=C2=A0|while there=E2=80=99s nothing wrong with them, even if you implement= ed them, \
=C2=A0|I do not believe that spam would be reduced one iota.
=C2=A0|
=C2=A0|I would suggest that one delve a bit into per-destination preauthori= zation \
=C2=A0|and how that might work from a UX perspective.
=C2=A0|
=C2=A0|In any case, I=E2=80=99m not sure a formal BoF is called for at this= point. \
=C2=A0| Maybe a bar bof.

New nuto-configurations (with old software), and old dangling
configurations on user boxes, maybe.=C2=A0 But new clients, or users
which create new accounts manually, or users in an environment
with an active administrator, i do not know.

I would vote for keeping complexity low, especially when
unnecessary.=C2=A0 For example the new Unix Alpine version ships with
direct XOAUTH2 support, including credential creation and renewal,
it needs JSON and HTTP for this, i think.=C2=A0 This makes more
dependencies etc. etc.=C2=A0 I would include that in the protocol, for
example, add a renew parameter, and let that cause an
additional/extended authentication response with includes the
renewed access token.=C2=A0 Just as an example, the entire additional
logic, or usage of external tools (like mine needs), etc., is
gone.=C2=A0 Lesser configuration for the user also.

And i personally do not think adding yet more to a protocol itself
is a right thing to do, especially if the protocol is only payload
for a security layer which has the potential to provide desired
additional information.=C2=A0 For example, EXTERNAL authentication
(which however does not seem to be supported well by widely used
server/s).=C2=A0 Or passing a client certificate as part of the
authentication step, if you all enforce XOAUTH2 then this can very
well be passed as a base64 token, too.=C2=A0 No need for more commands
which even possibly require roundtrips, or at least more C/S
answer/response interaction.
Requiring EXTERNAL has the nice property that the secure transport
is implicit.

--steffen
|
|Der Kragenbaer,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The= moon bear,
|der holt sich munter=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0he cheerfully= and one by one
|einen nach dem anderen runter=C2=A0 wa.ks himself off
|(By Robert Gernhardt)

_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art


--
Daniel Migault
Ericsson
_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art


--
Daniel Migault
Ericsson
--000000000000536d66059dc48330-- From nobody Tue Feb 4 10:53:59 2020 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0B9120137 for ; Tue, 4 Feb 2020 10:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1152-bit key) header.d=tana.it 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 HkVvwbvpNwBZ for ; Tue, 4 Feb 2020 10:53:56 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.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 B739F12008D for ; Tue, 4 Feb 2020 10:53:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1580842432; bh=wwiSaT8DfdGIOQcsP3L6eyspM/OAcyw6zHejZJAVmUw=; l=891; h=To:Cc:References:From:Date:In-Reply-To; b=CzHplLichIQ22X9eL6EdSOxNt8BniMqAQSWuWLIHZI/+UMvctiNL4YrXe5ZtUcPCB wDvxLvWyWPR0IDsNvIVZKhq4+tdxkXLv649QY22O+9N3GJaCkj2fFXALgOgpyEeADV W1dt6cQpstv+nfZ8mGlitAbIfDP6Fu/GBjtHiuRGRMKkEDdOSEckAkhHjtC1U Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005E39BDC0.0000424E; Tue, 04 Feb 2020 19:53:52 +0100 To: Michael Peddemors , Eliot Lear Cc: art@ietf.org References: <55abf67e-6a90-acff-a832-87a168d50522@linuxmagic.com> <298521FA-CC31-4888-99E3-7FE32419679C@cisco.com> <4150b6d5-ab85-ba54-f36e-96d36fb65026@linuxmagic.com> From: Alessandro Vesely Message-ID: Date: Tue, 4 Feb 2020 19:53:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <4150b6d5-ab85-ba54-f36e-96d36fb65026@linuxmagic.com> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [art] [FEEDBACK REQUEST] "Birds of a Feather" topic, email security threats X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 18:53:58 -0000 On Mon 03/Feb/2020 23:54:10 +0100 Michael Peddemors wrote: >>> >>> Call for Feedback: >>> >>> "Birds of a Feather (BOF)" on email authentication security. >>> > On 2020-02-03 2:44 p.m., Eliot Lear wrote: >> >> I would suggest that one delve a bit into per-destination preauthorization >> and how that might work from a UX perspective. >> > > I do want to point out, this is not about spam, but rather email security, > unless you are recommending that we enlarge the topic that much? The term "identity validation security" sounds overly specific. I'd suggest "authentication security" tout court. The fact is that "email authentication" has taken on the meaning of validating the domain ownership of the sending MTAs, see for example: https://www.iana.org/assignments/email-auth/email-auth.xml https://en.wikipedia.org/wiki/Email_authentication Best Ale -- From nobody Fri Feb 7 12:25:14 2020 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD841200D8 for ; Fri, 7 Feb 2020 12:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 mXKJTDAlVXI0 for ; Fri, 7 Feb 2020 12:25:11 -0800 (PST) Received: from smtp100.iad3a.emailsrvr.com (smtp100.iad3a.emailsrvr.com [173.203.187.100]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298A4120052 for ; Fri, 7 Feb 2020 12:25:11 -0800 (PST) X-Auth-ID: fluffy@iii.ca Received: by smtp5.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 033DB258D9; Fri, 7 Feb 2020 15:25:09 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (d75-159-246-1.abhsia.telus.net [75.159.246.1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 07 Feb 2020 15:25:10 -0500 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 7 Feb 2020 13:25:08 -0700 Cc: v3@ietf.org To: dispatch@ietf.org, "art@ietf.org" Message-Id: <5E861EFD-D506-4F33-95CA-BCA807B78ECD@iii.ca> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [art] RealTime Internet Peering for Telephony (RIPT) BoF Proposal X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 20:25:13 -0000 We are discussing a BOF at IETF 107 on the RIPT (used to be RIPP) on the = v3@ietf.org mailing list.=20 Please join the list at https://www.ietf.org/mailman/listinfo/v3 Thanks, Cullen=20 Description: Though extremely successful and deployed on massive scales, the Session Initiation Protocol (SIP) - as a 20 year old protocol - is showing its age. It is difficult to deploy SIP technologies into modern public cloud platforms. Its usage of raw IPs and ports, its load balancing techniques, and its state model, make it incompatible with services like global load balancers, autoscaling, service meshes, and so on.=20 =20 As such, the goal of this BoF is to create a new protocol that enables signaling and real-time interactive voice and video to operate = natively ontop of modern web platforms. This means that: =20 1. It needs to use HTTP URLs for addressing, and media and signaling can be sent in this way.=20 =20 2. It follows the HTTP connectionless model, in that, clients can = refresh their state and manipulate the state, and can do so from any different number of clients. =20 3. It aligns signaling and media state into a single piece of state, allowing clients to manipulate it with HTTP rpc operations =20 4. It utilizes modern http cloud security techniques, including OAuth, server-side TLS, and so on. =20 5. It utilizes modern techniques for load balancing and high = availability used in scaled web cloud environments =20 6. It makes use of modern http rpc techniques and data formatting =20 7. It follows modern web practice and makes security features mandatory, not optional (including e2e media encryption, though the media flows = HbH) =20 =20 The recent efforts to standardize HTTP3 using QUIC, make it possible to achieve the above without unacceptable latency and HOL blocking, = inherent in TCP-based protocols. =20 =20 To remedy this, a design team put together a draft specification called RIPP, which takes advantage of HTTP3 and QUIC to enable real-time communicatins over those protocols, without extending or changing them. =20 The purpose of the BoF is to gain consensus on the formation of a working group to work on this problem. A strong goal is to=20 build code and specifications simultaneously.=20 =20 =20 Relevant Drafts: =20 https://datatracker.ietf.org/doc/draft-rosenbergjennings-dispatch-ript/ https://datatracker.ietf.org/doc/draft-rosenberg-dispatch-ript-inbound/ https://datatracker.ietf.org/doc/draft-rosenberg-dispatch-ript-sipdiffs/ https://datatracker.ietf.org/doc/draft-rosenberg-dispatch-ript-webrtc/ =20 =20 From nobody Fri Feb 14 11:57:54 2020 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FCC120B37 for ; Fri, 14 Feb 2020 11:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Vg01HzhzkuOW for ; Fri, 14 Feb 2020 11:57:49 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 31B63120A99 for ; Fri, 14 Feb 2020 11:57:46 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id e18so11968631ljn.12 for ; Fri, 14 Feb 2020 11:57:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=NjcEeVeji9tZmSlYDCk2/1gLgCuGIMmK9Acg8en1Whc=; b=Y8IE2yB99wiqEWkuBBYlKZJw/uErOqBJV/d9ubriBdbCgsJpnA+7Qtrh285GZ6dBN2 9i9zsC1IBtHEgwTx+vgScMhiy58FSvnPnAZ+SpJETJDoyC3f0juCgIKmno5c6OPa2kwl ObgwTNms/p9n9DlH2ic9oZLKB7vXsC6ioe2Nq796nJOopRKV/2qLDT9f9l+3U/Uuy+wu z11k3+NsoKwM1qWz4kFw4OOjAB0Qa4nrcUHOOvYCraFKNDwSVwG0gvmneguuonLD51g3 esuYHdgEXWfqg1mkdSCpoV+jLvWOLg6ZR+ey41kyEQfU5ZZ1PEjdhGdpnl5r5815QILs szNA== 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=NjcEeVeji9tZmSlYDCk2/1gLgCuGIMmK9Acg8en1Whc=; b=QOoes70MzhxeZsF8mWwLPxv4kaAcI29DC9foUvmv/4ol+wH7JSaNi0+XcNiNGXaA+/ rSepNTOhrEDETIaEyXIwNyOvmmeYev1yVSpwod0ylUnuglLg0U14aUxRm5exetM6C6Tr xru60wHDHwYppwDUpi2I82G538FQDFTwIcS3xEluDnGGNrelV4pqz0L0WRdtyU6fKWiA 6BnNtiwDtotSdVbIxoBYMLawlvHGCP2pIYYWYq3j+q6pgK27K3uATOHFj2/xgBl/0Y5y lGF/jDKRb6F/G1iq4Uo4+VTuTy3xNOtKd6k4o78pznW1OwqENz4jAYvcy+2U+0CGNCeQ wnpw== X-Gm-Message-State: APjAAAVNMdDURsdvA59LOAntbehE0aX27ZfAk2amYKufxSu0A+lMthM2 DENUDaONNX5DSCFdihWK8GQ/9vRhrPVLt5TMx4jv7me0RyQ= X-Google-Smtp-Source: APXvYqzsjOMQXr7a8OlwsXmwcEKZgp0ivk3p6nlpqJ8+X/PXr5nMFrrK4yoQaZfRDs8IIDR1ptk+Px9pPlfnLk4bwHw= X-Received: by 2002:a2e:9256:: with SMTP id v22mr3210315ljg.45.1581710263460; Fri, 14 Feb 2020 11:57:43 -0800 (PST) MIME-Version: 1.0 From: Paul Jensen Date: Fri, 14 Feb 2020 14:57:32 -0500 Message-ID: To: art@ietf.org Content-Type: multipart/alternative; boundary="00000000000064a852059e8e9e1d" Archived-At: Subject: [art] Side meeting for IP address privacy on the web X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 19:57:53 -0000 --00000000000064a852059e8e9e1d Content-Type: text/plain; charset="UTF-8" I intend on holding a side meeting at IETF 107 to talk about IP address privacy on the web. As many browsers work to combat fingerprinting on the web, a user's IP address, the single most identifying fingerprintable surface, remains largely unprotected. Various browsers have acknowledged the fingerprintability of IP addresses or have proposed a solution: Chrome (https://github.com/bslassey/ip-blindness), Firefox ( https://blog.mozilla.org/blog/2019/09/10/firefoxs-test-pilot-program-returns-with-firefox-private-network-beta/), Safari (https://webkit.org/tracking-prevention-policy/), Brave ( https://brave.com/vpn0-a-privacy-preserving-distributed-virtual-private-network/). I'd like to hold a side meeting on this topic to start the conversation around IP address privacy on the web. Specifically with the goal of preventing IP from being used as a tracking vector, but trying to do so without breaking beneficial use cases such as DoS, fraud, spam and other abuse prevention. Agenda might look something like this: - What IP is used for - Spam, abuse, fraud, DoS protection - Geo IP - Ad targeting - others? - Privacy research - IP reidentification - IP fingerprinting - Proposals for IP blindness - VPN0 - FPN - Willful IP Blindness If you're interested in attending please let me know which days you have conflicting obligations in the morning slot. Paul --00000000000064a852059e8e9e1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I intend on holding a side meeting at IETF 107 to talk abo= ut IP address privacy on the web.=C2=A0 As many browsers work to combat fin= gerprinting on the web, a user's IP address,=C2=A0the single most ident= ifying fingerprintable=C2=A0surface, remains largely unprotected. Various b= rowsers have acknowledged the fingerprintability of IP addresses or have pr= oposed a solution: Chrome (https://github.com/bslassey/ip-blindness), Firef= ox (http= s://blog.mozilla.org/blog/2019/09/10/firefoxs-test-pilot-program-returns-wi= th-firefox-private-network-beta/), Safari (https://webkit.org/trackin= g-prevention-policy/), Brave (https= ://brave.com/vpn0-a-privacy-preserving-distributed-virtual-private-network/= ).=C2=A0 I'd like to hold a side meeting on this topic to start the= conversation around IP address privacy on=C2=A0the web.=C2=A0 Specifically= with the goal of preventing IP from being used as a tracking vector, but t= rying to do so without breaking=C2=A0beneficial=C2=A0use cases such as DoS,= fraud, spam and other abuse prevention.=C2=A0 Agenda might look something = like this:
    What IP is used for
    • Spam, abuse, fraud, DoS protection
    • Geo IP
    • Ad targeting
    • others?
  • Priva= cy research
    • IP reidentification
      • =
    • IP fingerprinting
  • Proposals for IP blindness
    • VPN0
    • FPN
    • Willful IP Blindness
If you= 're interested in attending please let me know which days you have conf= licting obligations in the morning slot.

Pau= l
--00000000000064a852059e8e9e1d-- From nobody Fri Feb 14 12:29:32 2020 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1CA120A99 for ; Fri, 14 Feb 2020 12:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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=nostrum.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 Kvb9vyk-jzat for ; Fri, 14 Feb 2020 12:29:28 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 18CF0120B3C for ; Fri, 14 Feb 2020 12:29:27 -0800 (PST) Received: from [172.17.121.48] (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 01EKTMDK071467 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 14 Feb 2020 14:29:23 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1581712164; bh=AFoDF0Rbn2Hi4fkUReC51N7XH5MpAuzcJhHi9+HsxuA=; h=Subject:To:References:From:Date:In-Reply-To; b=pIbwmsRiBqsvqLvDMOhRvRs/dUUCtOpC+lFQljxqipsyQhPsRYAjwAqr3Su3LoXQS sfxinF00jv1SWlFW6tFyOVvB8LqWjS3sXGsbmB1K2V8wCbAtk45bHK5oK8W3migA3P kHKt0UPD/HY4FOfP48eAN7yyY6fNQbN1FkJJUhzs= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be [172.17.121.48] To: Paul Jensen , art@ietf.org References: From: Adam Roach Message-ID: Date: Fri, 14 Feb 2020 14:29:16 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------19B723426574426AAD0719AD" Content-Language: en-US Archived-At: Subject: Re: [art] Side meeting for IP address privacy on the web X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 20:29:31 -0000 This is a multi-part message in MIME format. --------------19B723426574426AAD0719AD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2/14/2020 1:57 PM, Paul Jensen wrote: > > * VPN0 > * FPN > * Willful IP Blindness > To help those who might not be familiar with these last three bullets: VPN0 is something Brave is working on; overview is here: https://brave.com/vpn0-a-privacy-preserving-distributed-virtual-private-network/ FPN is the "Firefox Private Network", which is basically two different offerings. One is an in-browser VPN, and the other is a traditional whole-device VPN. I'm only passingly familiar with the technical details, but my understanding is that the VPN endpoint is run by Cloudflare, and that egress from their network is selected based on proximity to the destination site, making correlation of IP addresses more difficult than a typical VPN. There's a bit more description at https://fpn.firefox.com/ Willful IP Blindness is a concept that Brad Lassey (Google) has been working on recently, and is summarized at https://github.com/bslassey/ip-blindness/blob/master/README.md /a --------------19B723426574426AAD0719AD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 2/14/2020 1:57 PM, Paul Jensen wrote:
  • VPN0
  • FPN
  • Willful IP Blindness

To help those who might not be familiar with these last three bullets:


VPN0 is something Brave is working on; overview is here: https://brave.com/vpn0-a-privacy-preserving-distributed-virtual-private-network/

FPN is the "Firefox Private Network", which is basically two different offerings. One is an in-browser VPN, and the other is a traditional whole-device VPN. I'm only passingly familiar with the technical details, but my understanding is that the VPN endpoint is run by Cloudflare, and that egress from their network is selected based on proximity to the destination site, making correlation of IP addresses more difficult than a typical VPN. There's a bit more description at https://fpn.firefox.com/

Willful IP Blindness is a concept that Brad Lassey (Google) has been working on recently, and is summarized at https://github.com/bslassey/ip-blindness/blob/master/README.md

/a

--------------19B723426574426AAD0719AD-- From nobody Sun Feb 23 18:45:57 2020 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEC53A0829 for ; Sun, 23 Feb 2020 18:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.356 X-Spam-Level: X-Spam-Status: No, score=-0.356 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, 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 R0TO8IhYsm5k for ; Sun, 23 Feb 2020 18:45:53 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808633A0827 for ; Sun, 23 Feb 2020 18:45:53 -0800 (PST) Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 8288682DF1; Mon, 24 Feb 2020 03:45:47 +0100 (CET) To: Allison Mankin , "pearg@irtf.org" References: From: Fernando Gont Cc: art@ietf.org Message-ID: <7dad383b-fe17-85dd-609f-22db7f4efa55@si6networks.com> Date: Sun, 23 Feb 2020 12:44:46 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [art] [Pearg] Fwd: Side meeting for IP address privacy on the web X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 02:45:56 -0000 Folks, Unfortunately I will not be attending the next IETF meeting, but I felt like posting a few comments on the topic. Some of us have done a fair share of work in the area of "address privacy", among others, please see: * RFC7217/RFC8064: which replaces traditional stable IPv6 addresses with something more sensible (from a privacy point of view) * draft-ietf-6man-rfc4941bis: A revision of RFC4941 to fix a number of flaws in it. * RFC7721: Privacy analysis of IPv6 addresses. * draft-gont-6man-address-usage-recommendations: A document that, among other things identifies gaps that prevent us from doing more appropriate usage of IPv6 addresses. They try to address as much of the problem as is "addressable": Modulo the IID part of an address (which may unnecessarily leak information), all the topologically-dependent bit of an address are simply serving their purpose. Put another way, an address is a topologically-dependent identifier. So it *will* leak the position of the node in the network topology (that's why you use adressses in the first place, such that the network knows how to get packets back to you!). The browser "solutions" listed below are not really solutions: e.g., a VPN simply adds one extra layer of indirection, and essentially choose a different point in the network that gets to see all of the users' traffic, and is able to track users in a very easy way. dVPN would be, in a way, something along the lines of Tor? -- If so, why not Tor? As with DoH, relying on a single party to behave nicely, based on the (questionable) assumption that some party (in this case the local ISP) is evil, while another is just nice (in this case the VPN concentrator, or analogous for the browser extension) leads to, IMO, a more scary scary situation where a single entity could potentially go rogue, or be hacked, affecting the privacy of many more users. As with e.g. DoH, you don't really get privacy, but rather get to pick how gets to peak at your traffic. This is an important message to state clearly... and hopefully an argument such that browsers *never* enable this king of thing by default, as was the case with DoH in some cases. Thanks! Cheers, Fernando On 21/2/20 00:33, Allison Mankin wrote: > Hi PEARG, > > This is likely of interest to many of you. > > See you at IETF 107. > > ---------- Forwarded message --------- > From: *Paul Jensen* > > Date: Fri, Feb 14, 2020 at 14:58 > Subject: [art] Side meeting for IP address privacy on the web > To: > > > > I intend on holding a side meeting at IETF 107 to talk about IP address > privacy on the web.  As many browsers work to combat fingerprinting on > the web, a user's IP address, the single most identifying > fingerprintable surface, remains largely unprotected. Various browsers > have acknowledged the fingerprintability of IP addresses or have > proposed a solution: Chrome (https://github.com/bslassey/ip-blindness), > Firefox > (https://blog.mozilla.org/blog/2019/09/10/firefoxs-test-pilot-program-returns-with-firefox-private-network-beta/), > Safari (https://webkit.org/tracking-prevention-policy/), Brave > (https://brave.com/vpn0-a-privacy-preserving-distributed-virtual-private-network/). > I'd like to hold a side meeting on this topic to start the conversation > around IP address privacy on the web.  Specifically with the goal of > preventing IP from being used as a tracking vector, but trying to do so > without breaking beneficial use cases such as DoS, fraud, spam and other > abuse prevention.  Agenda might look something like this: >> >> * What IP is used for >> o Spam, abuse, fraud, DoS protection >> o Geo IP >> o Ad targeting >> o others? >> * Privacy research >> o IP reidentification >> o IP fingerprinting >> * Proposals for IP blindness >> o VPN0 >> o FPN >> o Willful IP Blindness > If you're interested in attending please let me know which days you have > conflicting obligations in the morning slot. > > Paul > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 25 16:09:46 2020 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBA93A0920 for ; Tue, 25 Feb 2020 16:09:44 -0800 (PST) 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, FREEMAIL_FROM=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 (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 wSIpcd098lyB for ; Tue, 25 Feb 2020 16:09:42 -0800 (PST) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 B30D43A091D for ; Tue, 25 Feb 2020 16:09:42 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id t17so765428ilm.13 for ; Tue, 25 Feb 2020 16:09:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=wE4AZ59Edj/MnrWkzrefXhltpV1LSfdRYsefDyBb0pY=; b=oCkLAE1D24VAq2iVf34vKLIirseFxjXJILOTtTTozj7C2F++AYZiimrYF3raMs8iBA oB5JVTZJ7LR26zM7+KeowMMI2DsCy2Q6qQc7TPNViPVGizsiBJegjcpYR6/WKobnFjp5 0NPOcoxrWkrit1/P6NYAIEnL3m35VkxrdqZycZLtZmOD6jGdfRTN/JtgTUBd6Lys02UR HhB6GfRHgXbi7VVPwt8LvXVOcCdiSLa6MWhPYRg54NBtSM1T8r8VTizik9EMkQ7EyLw3 PftXC2RbkMHsvTzsJDZQuGVBp2SamUt9ykBpXYWg6l0Vdxd8sQluOa+qI0vrQe4agTrK 4XOg== 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=wE4AZ59Edj/MnrWkzrefXhltpV1LSfdRYsefDyBb0pY=; b=LJ8lzubTLBLdv/osO/G3ZiSSUWLpz7BRNHnWnmj8Zvt94OejQHz6hmznrF8LX5QngS HScMx56R01gBYu7otp8r/6AZhd0EscI0F4v5dBTn99oYiX6EMtrwu574vWRQoTZiodH5 6tYucX6IcGkaVsJ/jfTKJ0+vMV3crdowFdtffac+K+dHiJOjDYHQvDZpxK4nnddGY6c6 Ay5hgZ1hqA5KvTTRctA9l/IwFvAELu+njWKTfm1Wnt1ZleffnsE3q0Uo57o/qlZTdmJ8 N0ZClT/r+BVgAI6FApGCZ6jAAWs5Mvk++FrOAUHAu+bTiXSUIdW9TYy3I5qimysWxVoU AT+Q== X-Gm-Message-State: APjAAAXhYcMClGfCefYlOMRMq8Q1gORXvQSdLhi390rE1sRlC4cS1cfA PDrhSUcthRJKQryH8zfzRWEnZ0Yk0SnMrkzGClR5MhW0 X-Google-Smtp-Source: APXvYqzn1HDi1gL35i+Y7VJNgyeeUSyQt1gbckyoRxZte3QapAzDkUjUfV3jnAYUjXt004Krm0xVm1qYAhaiCUUJY3M= X-Received: by 2002:a92:8f4b:: with SMTP id j72mr1246186ild.17.1582675781603; Tue, 25 Feb 2020 16:09:41 -0800 (PST) MIME-Version: 1.0 References: <158267385016.11018.7094919989285181688.idtracker@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Tue, 25 Feb 2020 16:09:30 -0800 Message-ID: To: art@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [art] Fwd: Last Call: (The LoST-Validation S-NAPTR Application Service Tag) to Informational RFC X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 00:09:44 -0000 I wanted to alert this group explicitly to the subject last call. If anyone has comments about it, please make them as specified below, to , rather than discussing it on this list. Thanks, Barry, ART AD ---------- Forwarded message --------- From: Barry Leiba Date: Tue, Feb 25, 2020 at 4:09 PM Subject: Fwd: Last Call: (The LoST-Validation S-NAPTR Application Service Tag) to Informational RFC To: I wanted to alert this group explicitly to the subject last call. If anyone has comments about it, please make them as specified below, to , rather than discussing it on this list. Thanks, Barry, ART AD ---------- Forwarded message --------- From: The IESG Date: Tue, Feb 25, 2020 at 3:37 PM Subject: Last Call: (The LoST-Validation S-NAPTR Application Service Tag) to Informational RFC To: IETF-Announce Cc: , Ben Campbell , The IESG has received a request from an individual submitter to consider the following document: - 'The LoST-Validation S-NAPTR Application Service Tag' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-03-31. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document adds the LoST-Validation service tag to the S-NAPTR Application Service Tag IANA registry. This tag is used by clients of the Location-to-Service Translation Protocol (LoST). The file can be obtained via https://datatracker.ietf.org/doc/draft-gellens-lost-validation/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-gellens-lost-validation/ballot/ No IPR declarations have been submitted directly on this I-D.