Memory Hole discussion / OpenPGP e-mail header protection

[Bjarni Runar Einarsson]

Hello GnuPG-devel!

Greetings from the Digital Citizenship and Surveillance Society
conference in Cardiff!

I am here with Meskio from Leap and Varac from Pixelated - they wanted
to talk Memory Hole, so I did my best to summarize for them what was
discussed at the summit last April.  I've also recently had
conversations about this with the folks at Lavaboom (Kernal is cc'ed).
So there is plenty of interest!

As I recall the plan last April was to continue the discussion here on
this mailing list, but as far as I can tell that never really
happened... until now. :-)

Below is the rough summary I wrote up for Meskio and Varac, of my
current understanding of the rough consensus that was reached in April.
Please correct me if I got anything wrong!  Sorry if this is really
dense, I'm happy to clarify any points which are unclear.


Links:

- DKG's talk/slides: https://www.ietf.org/proceedings/92/slides/slides-92-appsawg-0.pdf
- Mailpile 50% implementation: https://github.com/mailpile/Mailpile/blob/master/mailpile/contrib/experiments/experiments.py


Idea summary:

The goal is to extend the protection afforded by PGP/MIME to a subset of
the message headers, in particular the Subject line.

1. MOVE or COPY headers from the RFC2822 header into a MIME part of type
text/rfc822-headers
   1.1. Moving can provide confidentiality, when a message is encrypted
   1.2. Copying provides integrity, as a subset of the headers is signed
2. Protect the moved/copied header-part with a signature and/or
encryption as appropriate (PGP/MIME)
3. Visibility of the moved/copied headers can be controlled using the
Content-Disposition MIME attribute; this is useful for backwards
compatibility.


Refinements discussed at GnuPG summit:

1. The spec should be clear on how to structure mail (so where the
attachment goes, how many)
2. For ENCRYPTED mail:
   1. When headers are MOVED from the normal header (for privacy), SOME should be made visible to users with older MUAs
   2. Since only some headers are made visible, this implies two text/rfc822-headers parts:
      1. One visible part, in-line at top of message,
      2. A second attachment, containing non-critical headers
   3. Any given header should only be present in one of the two parts; unambiguous rules desirable. Visible headers override invisible?
3. For SIGNED (not encrypted) mail:
   1. All headers are visible; never MOVE headers
   2. No backwards compatibility concerns - so only one attachment with secure headers
4. The text/rfc822-headers part, when an attachment, should be given a
user-friendly name
5. How to present this in the user interface? Which headers are "secure"
or "insecure"
6. Which headers should be protected by default? Which headers are only
copied, which are moved?
7. Compatibility concerns:
   1. What breaks if we obscure the To / From / Cc / Reply-To / Errors-To / ...
   2. What breaks if we obscure the References: and In-Reply-To: headers?
   3. What breaks if we obscure the Message-ID?


Next steps:

1. Try implementing it, exchanging mail
2. Write up the spec, host the on modernpgp site?
3. Standardize?


I've made progress on 1, but I have nobody to exchange mail with... any
volunteers?

Cheers,
 - Bjarni

-- 
Sent using Mailpile, Free Software from www.mailpile.is
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP Digital Signature
URL: </pipermail/attachments/20150619/4ec24349/attachment-0001.sig>