Memory Hole discussion / OpenPGP e-mail header protection
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Tue Jun 30 06:13:47 CEST 2015
Many thanks to Bjarni and Patrick and everyone else who is moving this
On Sun 2015-06-28 13:31:10 -0400, Bjarni Runar Einarsson wrote:
> Patrick Brunschwig <patrick at enigmail.net> wrote:
>> > This allows for versioning and also binds the part to the message it
>> > applies to, which was one of the questions raised in April. I suspect
>> > we'll want to rename from "memoryhole" to something less cool but more
>> > descriptive sooner rather than later; "pgp-mime-headers" comes to mind?
>> The headers we protect are not PGP/MIME headers. I think something like
>> "protected-headers" or "secure-headers" would be better.
> I'm assuming this will be an extension to whatever RFCs discuss
> PGP/MIME, which is why I used those words. In fact, if/when there is an
> RFC for this, I'd vote for calling them rfc9999-headers. :-)
technically, these are rfc822 headers, even though rfc 822 has been
superceded by rfc 2822 and 5322. I think Patrick's suggestion of
protected-headers is a good one.
I'm not certain about inclusion of a message-id here, because the outer
(wrapping) message headers are not themselves protected. In general,
depending on non-signed context to interpret the meaning of signed
elements is trouble. I suppose it's possible that the ability to edit
the outer header isn't in any way exploitable, but if we believe that we
should have a clear, well-documented outline explaining why this is the
Do you think it's impossible to infer the correct header from the
placement within the MIME structure?
> Patrick wrote on another thread:
>> We should agree on certain specifics like how to display non-ASCII
>> characters in the memory hole headers. I would vote against using RFC
>> 2047, section 2 (e.g. =?UTF-8?blah?=), such that users can read the
>> headers easily if their mailers would not yet understand memory hole.
> I think I disagree. Although I applaud the sentiment (it's awesome that
> we're considering usability here), my gut feeling is the headers should
> be exactly like they are in the public header section. This will make
> both the spec and the code to implement it much simpler, lowering the
> bar to getting everyone to adopt this.
I agree with Bjarni here -- i don't want any different parsers to have
to apply to this stuff, and demanding that senders re-encode these
embedded headers seems like trouble to me.
fwiw, i think thunderbird already displays the headers correctly if
they're packed with RFC 2047 encodings.
> Ideally once things are properly integrated, the visible duplicate
> header section simply disappears and friendly green locks or checkmarks
> appear in the MUA header display instead.
yes, i think that's the right endgame.
> If users get annoyed by ugly extra header sections, maybe that will
> encourage them to upgrade their tools.
heh. not sure how convinced i am that this will happen at the timescale
you want, but maybe we can push it :)
More information about the Gnupg-devel