Subject: Re: [saag] Documenting the pretty Easy privacy (pEp) protocols

From: Bernie Hoeneisen <[email-masked]>
Date: Wed, 5 Jul 2017 13:52:41 +0200 (CEST)

Hernani,

I read your draft (draft-birk-pep-00) have a couple of minor questions:

Do you also intend to mitigate spam (using signed emails) or is this just 
a potential positive side effect?

Furthermore, I was looking at a the recent publication on "Sliding right 
into disaster: Left-to-right sliding windows leak" 
<https://eprint.iacr.org/2017/627.pdf>, that reveals possible attacks on 
libraries using sliding windows such as Libgcrypt, which is used by GnuPG.

Is the pEp approach also using affected libraries (as GPG does) and 
thus susceptible to such attacks?

cheers,
  Bernie

"Hernâni Marques (p≡p foundation)" <[email-masked]>

--

http://ucom.ch/
Modern Telephony Solutions and Tech Consulting for Internet Technology

On Thu, 29 Jun 2017, Hernâni Marques (p≡p foundation) wrote:

> Dear saag list members
>
> We, the p≡p (or pEp) foundation, have worked for some time on an
> architecture and system to achieve "Privacy by Default". pEp stands for
> pretty Easy privacy. Our goal is automatic message encryption (starting
> with email) to bring not just good, but also easy message encryption for
> the masses. That is, including people without any specialized computer
> expertise -- which effectively are the vast majority in any general
> population. :)
>
> There is a reference implementation to automatize key management,
> message transport and including a peer-to-peer key synchronization
> protocol to enable all sorts of users to securely engage in end-to-end
> encryption and with their messages (including email) readable across
> their different devices.
>
> We would be very happy if other people would engage in our efforts. We
> are interested in having pEp not just as software, but also documented
> as RFCs (for opportunistic encryption [RFC 7435], without vendor lock-in
> and with a peer-to-peer approach by design) to achieve what we call
> "Privacy by Default".
>
> To help the community to interoperate with the pEp implementions, we
> believe engaging with the IETF and documenting our work in RFCs is the
> way to go. We intend to document the general principles, message formats
> and alike and would like to get input and comment from IETF participants
> as we do that.
>
> We have published the most general Internet-Draft on pEp recently,
> outling the basic ideas and principles:
>
>   https://datatracker.ietf.org/doc/draft-birk-pep/
>
> Besides that, we have already been working on further Internet-Drafts
> (not yet submitted) that you can find (alongside with our reference
> implementation and some libraries we depend on) on our repos site:
>
>  https://letsencrypt.pep.foundation/dev/
>
> In addition, you can find a white paper outlining the necessity, spirit
> and concepts at:
>
>  https://pep.foundation/docs/pEp-whitepaper.pdf
>
> What is your opinion regarding our IETF contribution?
> We are looking forward to your opinions and feedback.
>
> Best regards
>
> Hernani (council member of p≡p foundation)
>
> PS:
> ISOC just announed their support of this work with a Beyond the Net
> Large Grant:
>
>
> https://www.internetsociety.org/blog/community-grants-community-projects/2017/06/announcing-beyond-net-results-june-2017-grants
>
> -- 
> p≡p foundation council member (https://pep.foundation)
>

---

From: Hernâni Marques (p≡p foundation) <[email-masked]>
Date: Thu, 6 Jul 2017 02:44:05 +0200

> Hernani,

Hello Bernie

> Do you also intend to mitigate spam (using signed emails) or is this
> just a potential positive side effect?

In the current implementation status, we don't have any special measures
a priori against spam.

However, two aspects

1)

If users can more easily verify their contacts (using
Trustwords and color signaling), some (little) spam, and more
importantly -- (spear-)phising messages -- might be detected. The
Privacy Status would turn red and read "under attack" if the underlying
fingerprints wouldn't match.

2)

Furtherly, if users would expect to receive at the very least encrypted
messages (e.g., from a bank or from an online shop), this could raise
their attention. An encypted message would show yellow or "secure" (in
terms of being encrypted properly) at least, given the vendor would have
the custuomer's pubkey and some system in place to automatically send
encrypted messages. By the adapter concept of pEp this can easily be
implemented, e.g. with the Python Adapter:

https://letsencrypt.pep.foundation/dev/repos/pEpPythonAdapter/

> Is the pEp approach also using affected libraries (as GPG does) and thus
> susceptible to such attacks?

Yes, for all platforms despite iOS we use GnuPG, which means it's in
principle affected.

A new version of libgcrypt was released:

    https://lists.gnupg.org/pipermail/gnupg-announce/2017q2/000408.html

What concerns the OpenPGP & email side, we require keys (available) to
be at least RSA-2048 -- by default pEp generates RSA-4096 key pairs for
each email account.

However, as Werner Koch himself states, you're screwed anyways if you
can run code on the target's machine:

"Note that this side-channel attack requires that the attacker can run
arbitrary software on the hardware where the private RSA key is used.
Allowing execute access to a box with private keys should be considered
as a game over condition, anyway." (cf. above link)

Greets

Hernani

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Jul 2017 15:20:46 +0100

Hiya,

First, I'd encourage you to keep on at this, it's
good that we keep striving for ways to improve e2e
interpersonal messaging security.

That said, I think it might be useful to try enumerate
the barriers to progress there and which of those
are being tackled in this work.

For example, both smime and pgp were designed at a
time when we mostly had one desktop MUA and don't
really support multiple MUAs and esp not web MUAs.
I guess you are trying to address that for folks
who buy into using plug-ins, but it's not clear to
me if that can really scale without support for
whatever solution one wants being available at the
major mail service providers and in widely-used
MUAs. (I wish it could scale, but fear it can't,
at least not without support from others who control
some of those MUAs and mail services.)

Anyway, I think it'd be useful to have a discussion
about that, i.e., being explicit about the set of
barriers to e2e security and the extent to which
the pEp scheme addresses some of those problems,
which wasn't really that clear to me from your
current draft.

Cheers,
S.

On 29/06/17 04:44, Hernâni Marques (p≡p foundation) wrote:
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Hernâni Marques (p≡p foundation) <[email-masked]>
Date: Wed, 12 Jul 2017 12:39:34 +0200

> Hiya,

Heyo Stephen

> interpersonal messaging security.

Yay, doing so! :)

> are being tackled in this work.

We'll be present at IETF-99 in Prague, so we're very happy to have
discussions with any interested folks and to present how we're
addressing the different scenarios one can think of, already in practice
or still TBD.

> some of those MUAs and mail services.)

We try to address this by providing adapters / bindings for all major
programming languages and programming platforms, such that e.g.:

- For Outlook there's a plug-in, which can also be deployed in mass.
- For Android there's a p≡p MUA (as no plug-in concept there).
- For iOS a new MUA is being created, which will also be the first with
OpenPGP-capable MUA with source code availalbe (otherwise, there's just
closed-source iPGMail, AFAICT).
- For Enigmail we've a cooperative project, whereas Enigmail will be in
Enigmail/p≡p mode by default as of 2.0 (if no prior OpenPGP setup can be
found), so that novice users get all steps automatized for e2ee.

There are other projects interested in cooperation. However, we cannot
(alone) work on everything at the same time. :)

The concept is that for commercial platforms there are companies (cf.
https://prettyeasyprivacy.com) creating solutions, which can integrate
in the already existing environments. There's also awareness of typical
barries, like virus scanning, leakage prevention systems and archving
present in big organizations and for legal reaons (e.g., archiving
regulations).

For the community side, the p≡p foundation is happy to collaborate and
provide any assistance necessary.

Most recently, we're setting up the process for automatic e2ee in web
MUAs, for which plug-ins (in spirit similar to
https://www.mailvelope.com/en) are necessary, which are able to talk to
a local p≡p implementaiton (e.g., interfacing to the p≡p engine
reference implementation the p≡p foundation provides) on one side, and
the web MUA API on the other side.

Of course, best-case would to have native p≡p support in the browsers,
supporting most of the popular web MUAs. But that's a political isuse.

> which wasn't really that clear to me from your

ACK

Concerning the Implementation Status, somewhat outlined in the
Internet-Draft (and above), we can discuss (and show) what we already
have in practice.

There we could also explain and show how multiple MUA support (when a
user has multiple MUAs; with p2p key synchronization) is handled.

Volker Birk as the software architect of the current implementations
will be present, too.

Greets

Hernani