Memory Hole discussion / OpenPGP e-mail header protection

[Daniel Kahn Gillmor]

On Wed 2015-07-01 05:19:25 -0400, Bjarni Runar Einarsson wrote:
> 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.

Do you have a preferred medium?  If so, please point me to it :)

We need to produce written documentation someplace that *will* convince
people :)

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

I don't think this is a full protection -- the parser will *also*
contain the protected-headers marker in Y and notice that they are
contained in a matching RFC2822 message.  shouldn't that trigger the
expected "signed header" display?

if not, why not?

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

yep, we should try to write up a stable of these attack scenarios.

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

agree.

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

Let's avoid "my proposal" and "your proposal" -- i don't want any ego
stakes in the discussion one way or the other :) Let's call the two
proposals "message-id matching" and "position matching"

Anyone implementing signature verification has to deal with positional
matching at some level anyway.  you have to know which bits are the
signature, and which other bits are the stuff signed (and which other
stuff is irrelevant).  So we're not going to avoid positional matching
in the first place.

furthermore, positional matching governs a signed mesage entirely on the
basis of the message itself.  The only contextual filter applied is "is
this in something that is presented as a message/rfc822 object in the
first place?"  -- and if the answer is no, then we simply don't
interpret the protected-header part as relevant to any message.

By contrast, mesage-id matching relies on unsigned context to interpret
the signed data, and to decide where to consider it relevant.  This is a
pattern that is asking for trouble.


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

I'm not suggesting that we'll decide to never deal with it.  But i think
the question of piecemeal signatures is orthogonal to memory-hole-style
protected headers, whether we are talking about message-id matching or
position matching.  If you want to think through piecemeal signatures,
let's do that, but in a distinct thread (we touched on their value
briefly at the OpenPGP summit, and i recognize that there are legitimate
scenarios where something like this would be useful; i'm just not sure
about the tradeoffs in terms of metadata leakage and UI complexity).

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

I'm disappointed that my explanations are apparently so bad they don't
register as explanations, but i'm willing to try harder :)

Making a system's interpretation of signed data subtly (or not so
subtly) dependent on unsigned context is a bad idea, because attackers
can exploit the unsigned context to force different interpretations of
the signed data.  message-id matching is worse in this regard than
position matching.

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

I'm not convinced that we should ever scare the user with warnings about
failed signatures anywhere.  I'm inclined to treat failed signatures
exactly the same as unsigned messages for the default UI case,
particularly because there's nothing most users can do to "fix" or even
effectively inspect the broken signature.

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

Yep, totally agree here -- as long as we're not claiming something about
the headers that is untrue (marking it as "signed" would be bad if there
was no signature), i see no harm in displaying an encrypted embedded
header preferentialy over the external header.

This raises a UI question though: how do we communicate to users that a
given header was hidden (encrypted) in transit, as opposed to a header
that was *not* hidden (encrypted) in transit?  Is this something that we
need to communicate to the user?  if so, how do we do it?  what visual
cues would be needed?

     --dkg