Memory Hole discussion / OpenPGP e-mail header protection

[Bjarni Runar Einarsson]

Good morning!

Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> > This is an important point. However, I think my scheme makes such
> > tampering easy to detect.
> 
> sure, the detection of tampering is easy!  it's figuring out what to do
> about it that's hard.

Yes. :)


> I think the argument here is that there are two kinds of attacks on
> signed headers:
> 
>  0) make you think a correctly-signed header is invalid
> 
>  1) make you think some other arbitrary data is correctly-signed
> 
> attack (0) has so many easy ways to accomplish (random bit flips,
> whitespace injection) that we shouldn't presume to defend against it.
> 
> attack (1) is harder to understand and work out.  I think you're
> claiming that it's impossible, but i don't see an exhaustive argument
> for it.  there are all kinds of ways that it could be repurposed in a
> bad way.

Yes, I think my scheme can be made secure. But I'm not sure how
best to explore and express that; mailing lists aren't a very good
medium for this sort of thing.


> Consider an attack like the following:
> 
>  B) Alice wants to cause some trouble.  She creates a new message Z
>     that is multipart/mixed, with two subparts, each of which are the
>     multipart-signed bodies of X and Y.  the part containing X's body is
>     marked Content-Disposition: inline, and the part containing Y's body
>     is marked Content-Disposition: attachment.

This attack is detected by my scheme. The parser will detect the
protected-headers markers in X and notices that they are not contained
in a matching RFC2822 message.

Your attack scenario is useful though, in that it clearly defines an
attack scenario which tools implementing Memory Hole should thwart.


> I'm not sure we're talking about the same thing when we're talking about
> "inferring position".  CSS selectors also work on tree-structured
> documents and they're able to recognize things like :
> 
>  body > div > span.mhole
> 
>  message/rfc822 > multipart/signed > multipart/mixed > message/rfc822-headers

Generating or evaluating paths like this is not easy with all
toolchains. CSS-style selectors are not a standard feature of MIME
libraries.

For example the default API exposed by the Python libraries for
traversing MIME, Message.walk(), doesn't make the necessary information
readily available. When using Message.walk() I cannot easily tell if
that multipart/mixed part is contained inside multipart/signed or
contained within message/rfc822.

See: https://docs.python.org/2/library/email.message.html#email.message.Message.walk

I can hack it, of course.  But my point here is only that what you are
asking is not something library authors have designed for, which *will*
complicate implementation. You haven't justified this cost.

My proposal on the other hand uses the Message-ID and the ad-hoc
parameters on the Content-Type attribute for what they were designed
for; signaling and identification, tooling should be pretty good and
implementations straightforward. :-)


> if we're looking at signatures, you're right that we won't be able to
> evaluate them until the entire message is processed.  This is not
> particularly negotiable.
> 
> If we want to talk about message signature structures that can sign
> messages piecemeal, that introduce whole new semantics and UI concerns,
> which i think we really don't want to get into.

I understand that you don't want to get into it, I'm sure it feels like
a giant can of worms and bike sheds.

But I also thing it would be a travesty if we created a new spec today
that was so inflexible that it wouldn't interoperate with forseeable
developments on that front.

Especially since the flexibility I'm after coincides with technical
simplicity in this case. I content that your prosposal to detect based
on position within the MIME structure is much more work to get right and
implementations will be more brittle.

I don't think you've ever really explained *why* you want to do things
this way, so I'm probably overlooking what benefits you forsee from
a position-based scheme as opposed to a marker like I proposed. Perhaps
you could explain in more detail if you think I'm overlooking something
important?


> > 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.
> 
> Why shouldn't the signed embedded header (if you have a valid signature
> that covers it) should just replace any tampered external header?

Maybe it should! This is certainly a simpler user experience.

If the rate of normal tampering is high enough, then there's no point
scaring the user with warnings about it when the app is able to recover
and correct the situation.


> > 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?
> 
> I'm not convinced this is as easy of an argument; the encryption doesn't
> necessarily contain a signature, right?

Without a signature, the encrypted part is theoretically just as easy to
tamper with (by replacing it wholesale) as any header in the public
part. However in practice it is still more reliable because we know all
the standard e-mail infrastructure doesn'tl mess with the contents.

Malicious actors will just do both. The implication of course is that if
there is no signature, we can't mark the headers as "verified". But we
might still prefer to display the ones that were less likely to have
been corrupted en route.

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/20150701/d7d333f9/attachment.sig>