Memory Hole discussion / OpenPGP e-mail header protection

[Daniel Kahn Gillmor]

Many thanks to Bjarni and Patrick and everyone else who is moving this
work forward!

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
case.

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 :)

    --dkg