Memory Hole discussion / OpenPGP e-mail header protection

[Bjarni Runar Einarsson]

Good morning!

Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> > 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.

True. It did occur to me that naming the header after an RFC actually
accomplishes the versioning that was requested, but that's probably
bordering on "too clever".  I agree that protected-headers is fine.

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

This is an important point. However, I think my scheme makes such
tampering easy to detect.

Consider that the proposed protected-headers attribute is not user
configurable; this attribute is not created if you attach a
message/rfc822-headers part by hand, and is not generated by the bounces
or delivery reports the MIME type is commonly used for.

However, the protected-headers attribute *is* protected by the PGP
encryption envelope or signature and is thus tamper resistant.

That means that IF it is present, then it MUST be contained within a
RFC2822 part with a matching message-ID. If that constraint is violated,
then the message has been tampered with.

Because message-IDs are important for so many things, threading etc.,
they are generally NOT routinely modified by MTAs or mailing lists. So
the rate of false posities should be quite low.

We were never going to be able to prevent tampering, the best we can do
is detect it. This scheme accomplishes that.

Does that hold water?


> Do you think it's impossible to infer the correct header from the
> placement within the MIME structure?

It is possible, but it becomes very awkward to work with. Since MIME is
effectively designed as a stream protocol (you can generate an infinite
stream of data which is also infinitely nested, and is still valid
MIME), it's just not designed to make inferring position (or relative
position) easy to do.

If you try to infer position you have two choices:

1. Parse the entire message into an intermediate data structure and
   then evaluate that.
2. Write code which evaluates a stream on the fly.

Option 1 perpetuates the performance nightmares of PGP/MIME: you can't
do anything useful with a message without parsing the whole thing. I'd
like to avoid encoding this bad behavior into the spec.

Option 2 is only marginally more performant than option 1, in that you
can stop parsing when you've found what you need - but you still need
to start at the beginning and parse everything from there, updating
counters as you go and hoping that your MIME library traverses the
message tree in a stable and predictable way.


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

Yes, but Patrick is correct that the verifiation parser will need to
correctly decode before comparing with the public header section.

The simple case is simple: encodings on the public header and the
protected one should simply be the same by default. If they're
different, then the message has been tampered with.

Unfortunately, such tampering is common. If I send 8bit headers (not
an uncommon thing to do in Iceland a few years ago), some MTAs might
helpfully re-encode the header section. A good implementation of Memory
Hole will avoid raising a false positive here, but I'm not sure how much
work is involved.

As always, signtures are the difficult bit and some implementations
might choose to not perform header validation at all just because it's
hard to get it right.

Encryption is easy: protected-headers in an encrypted part can just be
trusted blindly and overwrite whatever was in the public section. Is
there any need to warn the user about tampering (considering the high
expected rate of false positives), if we're able to recover from it
gracefully?

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/20150630/212cdadb/attachment.sig>