Hi folks!

I'm Bjarni of Mailpile. I wrote a blog post describing some of my misgivings about PGP/MIME and proposed an alternate "format" for sending encrypted mail.

Tankred encouraged me to share the post here, and solicit feedback. So here goes: https://www.mailpile.is/blog/2014-11-21_To_PGP_MIME_Or_Not.html

Thanks!

 - Bjarni

Whiteout Networks GmbH c/o Werk1

Hi Andris,

Do you feel the RFC2822 header metadata leak problem is worth
addressing? Have you guys given that any thought?

I understand that introducing another format is not something to do
lightly, which is why I structured my proposal as basically "Inline PGP
with training wheels". Speccing this formally would be a matter of
clearly defining the manifest format and recommending behaviors based on
that, which does seem doable.

I find it interesting that you are more optimistic than I about webmail
handling PGP/MIME in the near future. I looked at the Mailvelope bug
tracker (https://github.com/mailvelope/mailvelope/issues/41) and there
they agreed that parsing would be doable, but actually composing and
sending would be nigh impossible without explicit API support from the
webmail provider in question. Is there enough traction in the community
at the moment to get the webmail providers to let JS upload entire
fully-formed e-mails?

(In any case, the fact that we need to go around asking for such favors is a design flaw in PGP/MIME in my opinion, but that's maybe a little besides the point.)

Thanks!
 - Bjarni

Andris Reinman <and...@whiteout.io> wrote:
> Hi,
>
> I would vouch for PGP/MIME. It has been standardized long time ago and
> by now there should be a PGP/MIME capable solution for every platform,
> so supporting legacy clients makes less sense as time passes on. Air gap
> can be done with any client – just save the message as an eml file and
> open it in another machine. Today even webmail solutions are possible,
> for example Gmail exposes the raw message with the “show original” menu
> option – should be trivial for the browser plugin to load the message
> from this source. Introducing an additional format next to Inline PGP,
> PGP/MIME and S/MIME would make the field even more complicated as it is
> today and the standardization process would take ages.
>
> Best regards,
> Andris Reinman

--
I make stuff: www.mailpile.is, www.pagekite.net

Bjarni,

thanks for sharing your post here. To be honest, I don't think this is a decision other than Gmail/Yahoo can make.

Mailpile+Mailvelope+Whiteout do not have near as much resources/marketshare as the two big webmailers behind end-2-end. If they agree on an api to send PGP/MIME, this will likely become the defacto standard api for OpenPGP extensions and other webmailers might follow. If they decide against PGP/MIME and we are not part of that conversation, they will likely implement a different solution, which will have been a waste of time for us little guys.

I agree with Andris and think that inventing a new extension to OpenPGP is not an option for us little guys. It's a hard enough problem to bundle resources into a privacy/security centered email solution and then to find a market that cares. Inventing a new protocol is not something you can just do (unless you're Moxie of course ;)

Tankred

> --
> You received this message because you are subscribed to the Google Groups "Email.js Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to emailjs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--

Wow. I got the impression from your tweets that you wanted to discuss
things. I didn't join your mailing list just so you could tell me to go
home and wait for Google to tell me what to do...

You know they only reason they're even considering PGP/MIME is because I
pointed it out to them and the community spoke up, right? We absolutely
do have a voice, and of course we can invent a standard if we want to.
There are not a lot of PGP related email solutions in use out there, and
the ones that matter are FOSS projects like ours. That may change, but
today, this is our home turf. We can work together and improve things if
we want, we don't need permission from the big boys.

But I'm not going to try and drag you in a direction you clearly have no
interest in. Thanks for taking a look at the post, and we'll certainly
be in touch about other technical things later on.

Take care,
 - Bjarni

Hi Bjarni,

Just to make clear I have no objections about your protocol design – I think it would work. For example Outlook has done something similar for decades with its winmail.dat solution, so yours would basically be windmail.dat.pgp. If the client can’t open it on its own, you could download it and open in something that can understand the format.

The problem I have though is time – everything related to email has proven to take extremely long time. I think we are just about to be finally able to use PGP/MIME and this is more than 10 years old standard. As a comparison UTF-8 headers were standardized already in 2008 (RFC5335), thats 6 years ago, and we all still use mime encoded words – unless you are sending mail from php mail() command and have no clue of what you are doing. So I think that new standards should be created to resolve issues that are otherwise unresolvable but not really hope that you could use this standard yourself, at least not anytime soon. Encryption is already doable, the only unresolved PGP/MIME issue is sending but if you are already going to the extension route and not doing everything inside the webpage you could also route the outgoing message directly to users MSA (raw tcp support is not yet available for extensions but it is already fully working with browser apps).

Best regards,
Andris
--

Hi guys,

Andris Reinman <and...@whiteout.io> wrote:
> Just to make clear I have no objections about your protocol design – I
> think it would work. For example Outlook has done something similar for
> decades with its winmail.dat solution, so yours would basically be
> windmail.dat.pgp. If the client can’t open it on its own, you could
> download it and open in something that can understand the format.

Ouch, if I suggested something akin to winmail.dat then I probably
SHOULD go home and work on something else!

 ;-)

But that was not my intention at all - my suggestion was just that each
part be encrypted separately, and an extra part  (the manifest) be added
as a sort of extended signature for validating that everything got sent
correctly and as a container to carry (or simply validate) metadata we
don't want sent in the clear. Folks could ignore the manifest and their
experience would be very similar to receiving mail from an Enigmail user
today who has disabled outgoing PGP/MIME. My memories of winmail.dat
were significantly less pleasant...

Tankred wrote:
> This should not be a problem, as we agree that reading is not the
> issue for extensions. So it seems to be the sending from an
> extension that is under discussion.

Well, really, no. There are lots of extensions and clients out there
that have trouble reading that content today. Although there is hope
that that will improve over time, this problem is very really today. I
do appreciate your opinion that it's not a pressing concern though, that
is part of the feedback I was looking for when I wrote the post.

> Mailpile is a full stack IMAP/MIME/PGP client just like Whiteout.
> You can read/write PGP/MIME just like our client does without the
> constaints you mentioned for browser extensions.

Yes. The concern is how well our clients interoperate with the rest of
the ecosystem. Sending mail people can't read isn't good for either of
our projects.

As Andris said, it has taken 10 years for PGP/MIME support to mature...
and fundamentally I wonder whether it has even today. If anything, the
proportion of users using mail clients that have PGP/MIME support
available has gone down, not up. People have moved from desktops to the
web, and the webmail universe is only starting to address these problems
now.

The fact that you guys are unconcerned by this is useful information.

Either I'm ahead of the curve, or I'm just over-thinking things. :-)  I
can't tell which yet, but your feedback is useful either way.

Thanks!

 - Bjarni

--
I make stuff: www.mailpile.is, www.pagekite.net

Hi guys,

I just wanted to chime in.

1) You don't solve the RFC 2822 header metadata leak in your approach,
because you can't conceal the recipient in RFC 2822 as-is. The only
thing that comes to mind that conceals the recipients would be to have
an entry point (e.g. inbound MTA) in your organization that is the
recipient of a message and then forwards internally, like so:

From: f...@foo.org
To: entry...@organization.org
E1: To: j...@organization.org, ja...@organization.org
E1:
E2: PGP-MIME encrypted stuff GOES HERE

So E1 is encrypted with the public key of the entry node, E2 is
encrypted with the joe's and jack's public keys. The email entry node
would then reformat the message, replacing the message with everything
encrypted for E1.

2) The MIME header metadata leak for attachments was already solved by
PGP/MIME. As andris said, your manifest approach basically duplicates
what is included in the MIME headers
3) Your proposal is not resilient when it comes to traffic analysis.
the message length and ciphertext length still correlate...

I really advocate for "pain-driven" development for the
extensions-vs-PGP/MIME issue, where that guys that solve this problem
are the very same guys that have the problem in the first place. The
advantage is that those guys have the most valuable insight into what
the problem is and know all the angles to it... which is pretty much
the same way web technology standardization processes work today. :)

Cheers
Felix

Hi Felix!

Felix Hammerl <ma...@felixhammerl.com> wrote:
> 1) You don't solve the RFC 2822 header metadata leak in your approach,
> because you can't conceal the recipient in RFC 2822 as-is. The only
> thing that comes to mind that conceals the recipients would be to have
> an entry point (e.g. inbound MTA) in your organization that is the
> recipient of a message and then forwards internally, like so:

I think you misunderstand. My proposal allows for concealing all RFC2822
headers except for those necessary for delivery. They're moved to the
encrypted manifest and removed from the visible header.

Technically, in the RFC2822 header, you could get away with nothing but
a From: line with a bare e-mail address (for receiving bounces) and rely
on the SMTP envelope for delivery - this is equivalent to BCC'ing
everyone and works just fine. The To and Cc headers are largely social
conventions and my proposal implies they'd be reinstated before the user
interacts with the mail.  However in practice that breaks reply-all in
all the mail clients that don't understand the manifest, so I didn't go
that far in my examples. But technically, it would work just fine and we
could slowly move in this direction as support for manifests became
widespread.

This reduces metadata leakage on the mail server, in that the message at
rest in your remote mailbox no longer contains the full social graph -
snoops have to go to the mail server logs to find that, and such logs
are generally not kept for a very long time. So there is a real benefit,
even if it's not perfection.

Alternately, even when not encrypting, you duplicate any important
headers in the manifest anyway, so they are signed and can be validated
by the recipient.

> 2) The MIME header metadata leak for attachments was already solved by
> PGP/MIME. As andris said, your manifest approach basically duplicates
> what is included in the MIME headers

Yes. I'm avoiding PGP/MIME for compatibility reasons, as explained in
the post.

> 3) Your proposal is not resilient when it comes to traffic analysis.
> the message length and ciphertext length still correlate...

Yes. My proposal is weaker in that it leaks how many attachments there
are and roughly what their sizes are. This is the price of
compatibility. I suggested mitigating that by putting them all in a ZIP
archive, but I'm on the fence about how nice that is in practice. It's
an ugly hack.

> I really advocate for "pain-driven" development for the
> extensions-vs-PGP/MIME issue, where that guys that solve this problem
> are the very same guys that have the problem in the first place. The
> advantage is that those guys have the most valuable insight into what
> the problem is and know all the angles to it... which is pretty much
> the same way web technology standardization processes work today. :)

Fair enough!  Thanks for the comments. :-)