[Medup] IETF-104 minutes and materials

[Bernie Hoeneisen <[e-mail]>]

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: [e-mail];
   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