From nobody Tue Jun 4 07:46:19 2019 Return-Path: X-Original-To: medup@ietfa.amsl.com Delivered-To: medup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97E71200EB for ; Tue, 4 Jun 2019 07:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 daWNXbTZ166P for ; Tue, 4 Jun 2019 07:46:14 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 A4E511200DE for ; Tue, 4 Jun 2019 07:46:10 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1hYAhT-0004Be-NS for medup@ietf.org; Tue, 04 Jun 2019 16:46:07 +0200 Date: Tue, 4 Jun 2019 16:46:07 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: IETF MEDUP ML Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="37663318-683012471-1559659567=:15768" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Archived-At: Subject: [Medup] IETF-104 minutes and materials X-BeenThere: medup@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Missing Elements for Decentralized and Usable Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 14:46:18 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --37663318-683012471-1559659567=:15768 Content-Type: text/plain; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT Hi everybody During IETF-104 in Prague we had the first MEDUP (non-WG) meeting. * The meeting material and recordings can be found on: https://pep.foundation/docs/ietf/104/medup/ * The minutes are pasted below (for your convenience) and can be found on: https://etherpad.ietf.org/p/notes-ietf-104-medup Should any corrections be required, please let us know All the best Bernie et al. -- http://ucom.ch/ Tech Consulting for Internet Technology ------------------------------------------------------------------------------------ Minutes ======= MEDUP @ IETF-104: URL: https://pep.foundation/dev/repos/internet-drafts/raw-file/tip/medup/ietf-104/notes-ietf-104-medup-00.txt Revision 00: ------------ MEDUP -- Missing Elements for Decentralized and Usable Privacy Non-WG meeting @ IETF-104, Prague (Tyrolka room, Thu 2019-03-28, 18:15-19:30) * Mailing list: medup@ietf.org; subscribe: https://www.ietf.org/mailman/listinfo/MEDUP * Agenda: * Opening / Agenda Bashing [chairs] * Introduction to MEDUP [chairs] * Privacy Threat Modeling [Iraklis Symeonidis (SnT / uni.lu)] * The Missing Element in the Room [Gabriele Lenzini (SnT / uni.lu)] * Introduction to pEp [Hernani] * Document Status * draft-birk-pep-03 [Bernie] * draft-birk-pep-trustwords-03 [Bernie] * draft-marques-pep-handshake-02 [Bernie] * draft-marques-pep-rating-01 [Bernie] * draft-marques-pep-email-02 / draft-luck-lamps-pep-header-protection-01 [Claudio] * Open Issues [Bernie, Hernani] * Next Steps [chairs] * Open Mic (Last change: 2019-03-28 // rev: 08) * Slides / Streams: https://pep.foundation/docs/ietf/104/medup/ * Minutes * Opening / Agenda Bashing [chairs] * Chairs open the meeting including Note Well * No requests for agenda bashing * Introduction to MEDUP [chairs] * MEDUP is about of enhancements to application protocols for decentralized usable privacy * RFC 8280 has identified and documented important principles in such as Data Minimization, End-to-End and Interoperability in order to enable access to Human Rights. While (partial) implementations of these concepts are already available, today's applications widely lack Privacy support that ordinary users can easily handle. * In MEDUP these issues are addressed based on Opportunistic Security (RFC 7435) principles. Updates/usage clarifications to application level protocols such as email and XMPP are in scope. * There are other groups doing work in the area, such as HRPC, PEARG, DINRG * MEDUP aims go go beyond just principles, i.e., specifications for Running Code * Privacy Threat Modeling [Iraklis Symeonidis (SnT / uni.lu)] * Different users might have different privacy needs (journalists/whistleblowers, average users, corporate users) * There might be different attackers, from local attackers to global ones (global adversaries) * Different threats like detectability, linkability, identifiability, non-repudiation and others are to to be considered * Also legal frameworks exist which demand for concepts like data minimization (e.g., GDPR) * The Missing Element in the Room [Gabriele Lenzini (SnT/uni.lu)] * The missing link for privacy to work is actual usability * The missing element in the room is the average Internet user, which is not able to use the tools which exist * Real user has a persona that may be influenced * Psychology models should be considered (it's not the right approach to treat users as dummies). * Q&A * dkg * Asks for examples of user interaction work integrated in network protocols * Supports statements of the presentation: * Protocols should consider also the user; at the IETF we have never traditionally done that * Doesn't know how to move IETF towards UX considerations * Expects a lot of pushback within the IETF * Thinks pushback is wrong, but it is just a fact * Asks for pointer to existing hooks that we could use out of places like this * Gabriele (response to dkg) * Definitely from experients they have done, there are certain guidelines * For example interrupting the user's primary goal, going somewhere with warnings asking him to a take a decision, has proven to just bothering the user * As he wants to reach his primary goal and he doesn't care about whatever is in the middle * Condiering UX in the protocal to be made a principle matter of design * E.g., move user decisions to policy (e.g., HSTS) are good move; asking a user whether he/she trusts a web certificate was unnecessary * dkg * Summarizes: the simplest answer is not to offer any explicit controls to the user if you don’t have to * Gabriele: * If you do have to, you have to understand the psychology of the user, in such a way you’re not imagining him in doing what you want, but you consider that behavior as part of your system * Introduction to pEp [Hernani] * Aim to make text communications (i.e., email, chat, ...) private by default * Most users are unable to use existing encryption tools like GnuPG (properly) * Need to fix this usability challenge by automation * Not just “good”, but easy privacy * The pEp architecture consists of several building blocks * Existing RFCs are used whenever available (and usable) * Some pieces are currently missing (or incomplete) * pEp intends to document the missing pieces in the IETF * Running Code: www.pep.software * Document Status * draft-birk-pep-03 [Bernie] * Main document * Handling of crypto is traditionally seen as difficult and hinders widespread adoption * Missing pieces for easy decentralized useable privacy * Items relevant for all applications (email, chat, etc.) * draft-birk-pep-trustwords-03 [Bernie] * IANA registration of Trustwords * Mapping of hexadecimal stings to natural language words * Public registration of trustwords in different languages * draft-marques-pep-handshake-02 [Bernie] * Define easy authentication process for communication partners * Establishing trust relationship based on public keys using trustwords * draft-marques-pep-rating-01 [Bernie] * Easy understandable representation of Privacy Status * Description of different rating codes to inform a user on the Privacy Status * draft-marques-pep-email-02 / draft-luck-lamps-pep-header-protection-01 [Claudio] * Define missing pieces for email * Message Format 2 is wrapping messsages to be able to process those * There are backward compatibility issues to be considered * Questions / Discussion * Sara * Wants to see what elements need more reasearch and shouldn't initially be part of standardization process * Need to look at the distinctions of the layers between pure protocol specification, user interaction and usability; these are three distinct areas that in some cases are quite overlapped and that can possibly get better attention by being unpicked * There are many protocols that are disguised here, not just email * Parts that aren’t directly related to protocol specicifiactions could move out to research * Interested in a conversation what active research areas are in place to work on * Some of these elements could benefit from coming to for example PEARG and then feed back for changes in the protocols * It's fascinating work, it's pushing what we do at IETF, very much, at bit of care in choosing where it gets done could lead to much better reception of the work * If it is framed in the right way, we could be more receptive to it * Bernie * Proponents are open to dicuss this * Invites to send a summary to the MEDUP mailing list for discission, to better understand how we can address this matter * dkg * Fascinating large amount of work that is presented here * In LAMPS mentioned the course of the deployed base; is the fundamental problem we struggle here at IETF * Even if we can get everybody to switch today, I still wanna read my own mail, which don't adhere to that specification * And we’re not getting everybody to switch, just because of the deployed base * Would be interested in thinking about what the usability issues are and what the usability approaches are for dealing with interoperability with non-compliant partners * While we know what is the right thing to do for generation [outgoing], and yet we are regularly obliged to consume [incoming] non-compliant data * That's a very tough question * Wants to hear the general ideas about how to address that * Hernani * The pEp project has a lot of experience in the field * Not yet clear how big the problem really is * Most people aren't encrypting at all * Far less than 1% actually use encryption at this time * Interested of documenting these issues in general, maybe in MEDUP * Independent of pEp, as this affects all projects in this area, including pEp or Autocrypt * Invites particularly also Autocrypt folks to engage with MEDUP * dkg * Need to find anyone to catalog the most common ways email is broken (observations and recommendations to go forward) * Hernani * MEDUP discussions should not be just about pEp * Should be open for other approaches * Gabriele * Rating draft: rating model should be multidimensional (not linerar) * Hernani * pEp is open to change protocols [if there are better ways to achieve the goals] * Open Issues [Bernie, Hernani] * Will not discuss all issues on the slides due to time constraints * Slide 1/5: Should the very 1st message (TOFU, no key avaialble for encryption) be signed? * What is the added value? * Does it lead to false peception of security? * Christian: * Depends, sometime repudiation is wanted * There might be a value for signing, e.g., sometimes signing metadata may be needed (not the message itself) * Slide 2/5: Trustwords, what is the best charset? * ASCII 7bits, UTF-8, HTML-like encoding, IDNA, ...? * Normalization of UTF-8 was proposed on the mailing list (similar sounding words map to the same UTF-8 representation) * [Discussion deviated and cut by chair due to time constraints] * Next Steps [chairs] * pEp email I-D will be updated * pEp key synchronization I-D is planned to be published * Continue discussion on MEDUP mailing list * Continue to hold non-WG meetings * Request BoF when ready * Open Mic --37663318-683012471-1559659567=:15768-- From nobody Fri Jun 7 03:28:43 2019 Return-Path: X-Original-To: medup@ietfa.amsl.com Delivered-To: medup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFC41201E9 for ; Fri, 7 Jun 2019 03:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni.lu 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 teVW4cRfwKw0 for ; Fri, 7 Jun 2019 03:28:38 -0700 (PDT) Received: from smtp1.uni.lu (smtp1.uni.lu [IPv6:2001:a18:a:c5::d]) (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 A749E12003E for ; Fri, 7 Jun 2019 03:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni.lu; i=@uni.lu; q=dns/txt; s=DKIM; t=1559903317; x=1591439317; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=60fNc49HnLu/gxgNuBTWG+ZBIUJwgW7zx8YQUoPRm3Q=; b=BpBjkE1PPD2OzicGwq0iYBCPtWO6szFrnpbu3iBf5LQREpMCx4uDw3dn f8dTg5tzJE0MQGj6uHOe4/UZ4AJ7DJFlfXAB7kyxueXquT2hA4pQVLpFM SdlNOMheC73vl4EYeGjwSA7XlMv0w7v+sNOE/9gfCrfhrU9hZbIs8rCzI 4qEF8h5dHcWSW4BnJBZl+xMcrZLConuh4WFuiDMNiQS9f5yuPV4HIZFhi TLG+q9VRflCrGy59ITk4QyfwrmJ//NXdlR6gpdq6g7e1ZATu30vdja0ZT mRdNzpyZsi9Ud72BKUBXvuuJ0MFlnih0gpDb4MoWUEbOa2J5SAH84dFGt g==; Authentication-Results: smtp1.uni.lu; spf=Fail smtp.mailfrom=iraklis.symeonidis@uni.lu; dkim=none (message not signed) header.i=none; dmarc=fail (p=none dis=none) d=uni.lu X-IronPort-AV: E=Sophos;i="5.63,562,1557180000"; d="asc'?scan'208";a="22034428" From: Iraklis Symeonidis Message-ID: <211C62E4-B5AA-4183-803E-916C88F24444@uni.lu> Content-Type: multipart/signed; boundary="Apple-Mail=_4B54EDE7-2C48-40AE-BB7E-A7884A34ECF9"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 7 Jun 2019 12:28:22 +0200 In-Reply-To: CC: Iraklis Symeonidis To: References: X-Mailer: Apple Mail (2.3445.104.11) X-Originating-IP: [10.240.10.17] X-ClientProxiedBy: Veil2017.uni.lux (2001:a18:a:90::73) To lydia2017.uni.lux (2001:a18:a:90::6f) Archived-At: Subject: Re: [Medup] MEDUP Digest, Vol 4, Issue 1 X-BeenThere: medup@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Missing Elements for Decentralized and Usable Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 10:28:41 -0000 --Apple-Mail=_4B54EDE7-2C48-40AE-BB7E-A7884A34ECF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi guys, Can you please add also Borce in the MEDUP mailing list and in all = communications that you are forwarding to us? Thanks! Best, Iraklis = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94 Post-doctoral researcher SnT / APSIA, University of Luxembourg JFK Building, 29, avenue JF Kennedy, L-1855, Luxembourg (+352) 46 66 44 5594 www.iraklissymeonidis.info = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94 > On 4 Jun 2019, at 21:00, medup-request@ietf.org wrote: >=20 > Send MEDUP mailing list submissions to > medup@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/medup > or, via email, send a message with subject or body 'help' to > medup-request@ietf.org >=20 > You can reach the person managing the list at > medup-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of MEDUP digest..." > Today's Topics: >=20 > 1. IETF-104 minutes and materials (Bernie Hoeneisen) >=20 > From: Bernie Hoeneisen > Subject: [Medup] IETF-104 minutes and materials > Date: 4 June 2019 at 16:46:07 GMT+2 > To: IETF MEDUP ML >=20 >=20 > Hi everybody >=20 > During IETF-104 in Prague we had the first MEDUP (non-WG) meeting. >=20 > * The meeting material and recordings can be found on: > https://pep.foundation/docs/ietf/104/medup/ >=20 > * The minutes are pasted below (for your convenience) and can be found = on: > https://etherpad.ietf.org/p/notes-ietf-104-medup >=20 > Should any corrections be required, please let us know >=20 >=20 > All the best > Bernie et al. >=20 >=20 > -- >=20 > http://ucom.ch/ > Tech Consulting for Internet Technology >=20 > = --------------------------------------------------------------------------= ---------- >=20 > Minutes > =3D=3D=3D=3D=3D=3D=3D >=20 > MEDUP @ IETF-104: > URL: = https://pep.foundation/dev/repos/internet-drafts/raw-file/tip/medup/ietf-1= 04/notes-ietf-104-medup-00.txt >=20 >=20 > Revision 00: > ------------ >=20 > MEDUP -- Missing Elements for Decentralized and Usable Privacy > Non-WG meeting @ IETF-104, Prague (Tyrolka room, Thu 2019-03-28, = 18:15-19:30) >=20 > * Mailing list: medup@ietf.org; > subscribe: https://www.ietf.org/mailman/listinfo/MEDUP >=20 > * Agenda: > * Opening / Agenda Bashing [chairs] > * Introduction to MEDUP [chairs] > * Privacy Threat Modeling [Iraklis Symeonidis (SnT / uni.lu)] > * The Missing Element in the Room [Gabriele Lenzini (SnT / uni.lu)] > * Introduction to pEp [Hernani] > * Document Status > * draft-birk-pep-03 [Bernie] > * draft-birk-pep-trustwords-03 [Bernie] > * draft-marques-pep-handshake-02 [Bernie] > * draft-marques-pep-rating-01 [Bernie] > * draft-marques-pep-email-02 / > draft-luck-lamps-pep-header-protection-01 [Claudio] > * Open Issues [Bernie, Hernani] > * Next Steps [chairs] > * Open Mic >=20 > (Last change: 2019-03-28 // rev: 08) >=20 > * Slides / Streams: https://pep.foundation/docs/ietf/104/medup/ >=20 > * Minutes > * Opening / Agenda Bashing [chairs] > * Chairs open the meeting including Note Well > * No requests for agenda bashing >=20 > * Introduction to MEDUP [chairs] > * MEDUP is about of enhancements to application protocols for > decentralized usable privacy > * RFC 8280 has identified and documented important principles in = such > as Data Minimization, End-to-End and Interoperability in order to > enable access to Human Rights. While (partial) implementations of > these concepts are already available, today's applications widely > lack Privacy support that ordinary users can easily handle. > * In MEDUP these issues are addressed based on Opportunistic = Security > (RFC 7435) principles. Updates/usage clarifications to = application > level protocols such as email and XMPP are in scope. > * There are other groups doing work in the area, such as HRPC, = PEARG, > DINRG > * MEDUP aims go go beyond just principles, i.e., specifications for > Running Code >=20 > * Privacy Threat Modeling [Iraklis Symeonidis (SnT / uni.lu)] > * Different users might have different privacy needs > (journalists/whistleblowers, average users, corporate users) > * There might be different attackers, from local attackers to = global > ones (global adversaries) > * Different threats like detectability, linkability, = identifiability, > non-repudiation and others are to to be considered > * Also legal frameworks exist which demand for concepts like data > minimization (e.g., GDPR) >=20 > * The Missing Element in the Room [Gabriele Lenzini (SnT/uni.lu)] > * The missing link for privacy to work is actual usability > * The missing element in the room is the average Internet user, = which > is not able to use the tools which exist > * Real user has a persona that may be influenced > * Psychology models should be considered (it's not the right = approach > to treat users as dummies). > * Q&A > * dkg > * Asks for examples of user interaction work integrated in = network > protocols > * Supports statements of the presentation: > * Protocols should consider also the user; at the IETF we = have > never traditionally done that > * Doesn't know how to move IETF towards UX considerations > * Expects a lot of pushback within the IETF > * Thinks pushback is wrong, but it is just a fact > * Asks for pointer to existing hooks that we could use out of > places like this > * Gabriele (response to dkg) > * Definitely from experients they have done, there are certain > guidelines > * For example interrupting the user's primary goal, going > somewhere with warnings asking him to a take a decision, has > proven to just bothering the user > * As he wants to reach his primary goal and he doesn't care = about > whatever is in the middle > * Condiering UX in the protocal to be made a principle matter = of > design > * E.g., move user decisions to policy (e.g., HSTS) are good = move; > asking a user whether he/she trusts a web certificate was > unnecessary > * dkg > * Summarizes: the simplest answer is not to offer any explicit > controls to the user if you don=E2=80=99t have to > * Gabriele: > * If you do have to, you have to understand the psychology of = the > user, in such a way you=E2=80=99re not imagining him in doing = what you > want, but you consider that behavior as part of your system >=20 > * Introduction to pEp [Hernani] > * Aim to make text communications (i.e., email, chat, ...) private = by > default > * Most users are unable to use existing encryption tools like GnuPG > (properly) > * Need to fix this usability challenge by automation > * Not just =E2=80=9Cgood=E2=80=9D, but easy privacy > * The pEp architecture consists of several building blocks > * Existing RFCs are used whenever available (and usable) > * Some pieces are currently missing (or incomplete) > * pEp intends to document the missing pieces in the IETF > * Running Code: www.pep.software >=20 > * Document Status >=20 > * draft-birk-pep-03 [Bernie] > * Main document > * Handling of crypto is traditionally seen as difficult and = hinders > widespread adoption > * Missing pieces for easy decentralized useable privacy > * Items relevant for all applications (email, chat, etc.) >=20 > * draft-birk-pep-trustwords-03 [Bernie] > * IANA registration of Trustwords > * Mapping of hexadecimal stings to natural language words > * Public registration of trustwords in different languages >=20 > * draft-marques-pep-handshake-02 [Bernie] > * Define easy authentication process for communication partners > * Establishing trust relationship based on public keys using > trustwords >=20 > * draft-marques-pep-rating-01 [Bernie] > * Easy understandable representation of Privacy Status > * Description of different rating codes to inform a user on the > Privacy Status >=20 > * draft-marques-pep-email-02 / > draft-luck-lamps-pep-header-protection-01 [Claudio] > * Define missing pieces for email > * Message Format 2 is wrapping messsages to be able to process = those > * There are backward compatibility issues to be considered >=20 > * Questions / Discussion > * Sara > * Wants to see what elements need more reasearch and shouldn't > initially be part of standardization process > * Need to look at the distinctions of the layers between pure > protocol specification, user interaction and usability; these > are three distinct areas that in some cases are quite = overlapped > and that can possibly get better attention by being unpicked > * There are many protocols that are disguised here, not just = email > * Parts that aren=E2=80=99t directly related to protocol = specicifiactions > could move out to research > * Interested in a conversation what active research areas are = in > place to work on > * Some of these elements could benefit from coming to for = example > PEARG and then feed back for changes in the protocols > * It's fascinating work, it's pushing what we do at IETF, very > much, at bit of care in choosing where it gets done could = lead > to much better reception of the work > * If it is framed in the right way, we could be more receptive = to > it > * Bernie > * Proponents are open to dicuss this > * Invites to send a summary to the MEDUP mailing list for > discission, to better understand how we can address this = matter > * dkg > * Fascinating large amount of work that is presented here > * In LAMPS mentioned the course of the deployed base; is the > fundamental problem we struggle here at IETF > * Even if we can get everybody to switch today, I still wanna = read > my own mail, which don't adhere to that specification > * And we=E2=80=99re not getting everybody to switch, just = because of the > deployed base > * Would be interested in thinking about what the usability = issues > are and what the usability approaches are for dealing with > interoperability with non-compliant partners > * While we know what is the right thing to do for generation > [outgoing], and yet we are regularly obliged to consume > [incoming] non-compliant data > * That's a very tough question > * Wants to hear the general ideas about how to address that > * Hernani > * The pEp project has a lot of experience in the field > * Not yet clear how big the problem really is > * Most people aren't encrypting at all > * Far less than 1% actually use encryption at this time > * Interested of documenting these issues in general, maybe in > MEDUP > * Independent of pEp, as this affects all projects in this = area, > including pEp or Autocrypt > * Invites particularly also Autocrypt folks to engage with = MEDUP > * dkg > * Need to find anyone to catalog the most common ways email is > broken (observations and recommendations to go forward) > * Hernani > * MEDUP discussions should not be just about pEp > * Should be open for other approaches >=20 > * Gabriele > * Rating draft: rating model should be multidimensional (not > linerar) > * Hernani > * pEp is open to change protocols [if there are better ways to > achieve the goals] >=20 > * Open Issues [Bernie, Hernani] > * Will not discuss all issues on the slides due to time = constraints > * Slide 1/5: Should the very 1st message (TOFU, no key avaialble = for > encryption) be signed? > * What is the added value? > * Does it lead to false peception of security? > * Christian: > * Depends, sometime repudiation is wanted > * There might be a value for signing, e.g., sometimes signing > metadata may be needed (not the message itself) > * Slide 2/5: Trustwords, what is the best charset? > * ASCII 7bits, UTF-8, HTML-like encoding, IDNA, ...? > * Normalization of UTF-8 was proposed on the mailing list = (similar > sounding words map to the same UTF-8 representation) > * [Discussion deviated and cut by chair due to time = constraints] >=20 > * Next Steps [chairs] > * pEp email I-D will be updated > * pEp key synchronization I-D is planned to be published > * Continue discussion on MEDUP mailing list > * Continue to hold non-WG meetings > * Request BoF when ready >=20 > * Open Mic >=20 >=20 > MEDUP mailing list > MEDUP@ietf.org > https://www.ietf.org/mailman/listinfo/medup --Apple-Mail=_4B54EDE7-2C48-40AE-BB7E-A7884A34ECF9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE+Yn961/nczDzObHqwuR8VPBWdCcFAlz6PEYACgkQwuR8VPBW dCflqxAAiUuNrqtRGZztZTaSQ9v5O8/oZdOKSGnrlAMG8VMmuY6x4gOseJ6uzDW3 fyQ0QKOmYWrP8dXqEcb84h1qk4CX2BIOc71YZ9S8bn/Aw4abwqM874c+0O/soWnt DaeA/0B1LEyslWM86C2iZl8hGQISakqU32rw6zvUzXKMkB+jxDDAnUVEu4g35kVY DwCXFb8XDAuy5+hKAL4X9O2QRxgdevKQu2YmlSZGU2DFprhOj+rG3VCnOiOYtwt9 A8LNU9R7lRejb+ZKAulpoMEBJBBISUXU7MP3QECLYJcrTZ0K2uoUhV3y39t9Sdsu OJCl6ZJZ1aCDEPxoaydSzg2l9xh6RXnTjsL5Kc6Mh7mvt4yhQhtFSzWkRjNAeWVr nlDpKi464E8R7odpu2IotNzFdDJtbbyDeO5ReRTbMcFCtx5uHfaeoyxS78Xkz3hN wKUzEUxvRDRgZkHLWnR2KhYgGhz/iRxnhiY1RawMNFrVVD8yDq2GMMsc/IYCkAk3 F2N84q+eT1/msclxft8JZqU2AwkC03xITaMpNxTC0R2oZ1ZcgnpnoP2hie5Z6n0O fIE0U+/g1BRLmg3jBAh54/HY+X/+YGMfpvJJmohw53qJektCuEQJPrrlPJTNFZEy 9QKg+rNkBbdn74hEt2zHbgKi87qMJfeMm1JlsglDpOnUPnfCK30= =p1qs -----END PGP SIGNATURE----- --Apple-Mail=_4B54EDE7-2C48-40AE-BB7E-A7884A34ECF9--