Add MEDUP notes of IETF-104 meeting in Prague.

Hernâni Marques 4 years ago
parent 6e4029d4dc
commit 0593afa00b

@ -0,0 +1,224 @@
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:; subscribe:
* Agenda:
* Opening / Agenda Bashing [chairs]
* Introduction to MEDUP [chairs]
* Privacy Threat Modeling [Iraklis Symeonidis (SnT /]
* The Missing Element in the Room [Gabriele Lenzini (SnT /]
* 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
* Open Issues [Bernie, Hernani]
* Next Steps [chairs]
* Open Mic
(Last change: 2019-03-28 // rev: 08)
* Slides / Streams:
* 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,
* MEDUP aims go go beyond just principles, i.e., specifications for
Running Code
* Privacy Threat Modeling [Iraklis Symeonidis (SnT /]
* 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/]
* 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
* 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
* 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
* E.g., move user decisions to policy (e.g., HSTS) are good move;
asking a user whether he/she trusts a web certificate was
* dkg
* Summarizes: the simplest answer is not to offer any explicit
controls to the user if you dont have to
* Gabriele:
* If you do have to, you have to understand the psychology of the
user, in such a way youre 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
* Most users are unable to use existing encryption tools like GnuPG
* 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:
* 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
* draft-marques-pep-email-02 / draft-luck-lamps-pep-header-protection-01
* 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 arent 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 were 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