MIME or inline signature ?

[Doug Barton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2/15/15 12:26 PM, Daniel Kahn Gillmor wrote:
| On Sat 2015-02-14 16:36:08 -0500, Doug Barton wrote:
|> FWIW, I hate this debate, and try hard to stay out of it. But it really
|> bothers me when people spread factually incorrect information,
|> especially when they try to use that as the basis of their arguments
|> for/against one method or the other.
|
| I feel the same way.

... and yet, you not only responded to this thread (fair enough, so did
I), but you took the time to write up an entire web page full of FUD on
the topic. :)  Methinks you do protest too much.

|>> * AFAIK, inline gpg has issues with non-ascii characters. 😞 Correct
me if I'm
|>>     wrong.
|>
|> This hasn't been true for almost a decade, assuming that the person
|> using the non-ASCII characters has correctly set up their environment.
|> And FWIW, it's also not true that PGP/MIME will be 100% successful when
|> one of the communicants has not correctly set up their environment.
|
| if we're talking about signed messages with the possibility of an
| adversary who can modify the messages, then the the fact is that inline
| PGP messages have no way of securely indicating the character encoding
| in use.  This means that an attacker can actually modify how the
| cleartext message is interpreted by fiddling with data *outside* the
| message body.
|
| If we're talking about encrypted messages, the same problem holds.

If you are referring to the display of the message after it's decrypted
(which is influenced by the content-encoding header) then see below.

| I demonstrate this in the "Message tampering through header
| substitution" section here:
|
|   https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/

You demonstrate what you claim to be a collision where signatures verify
in both cases (I am willing to give you the benefit of the doubt, I
haven't tested it). However the collision isn't meaningful. I don't
think anyone would receive a message that says, "pay <character for
pounds sterling><Hebrew character>13" and think that it was what the
recipient intended to send. Not to mention, if you were actually sending
a message that meant to indicate an amount in monetary units you would
spell out the amount in addition to displaying it numerically.

Show me a *meaningful* collision that your attack surface is vulnerable
to, and I'll pay more attention to it.

| the lesson here is: if you care about getting the intended textual
| message through to your peer, you need to embed some information about
| the formatting *within* the signature.  PGP/MIME provides a clear,
| well-defined way to provide that information.

I don't deny the fact that PGP/MIME encodes the charset info in the body
that is signed. I simply deny that this fact is meaningful to the
overwhelming majority of users.

|> It's also not true that PGP/MIME protects you from metadata analysis.
|> The messages are not "one big blob," they are actually separated into
|> parts, including the attachments. It's trivial to see how many
|> attachments are in a message just by analyzing the MIME headers, whether
|> the message/attachments are encrypted or not.
|
| If we're talking about PGP/MIME encrypted messages, this is not correct.

The OP was talking specifically about signed messages with attachments.
I made the leap to encrypted, and you're correct, I'm at least partially
wrong about that. (I vaguely recall that there is a way to do an
encrypted MIME message with attachments that does not end up in one big
blob, but I may be mistaken about that. It's been a while since I poked
that stuff.)

However in the context of signed but not encrypted, my point still stands.

Some more errors from your web page:

1. Enigmail is very clear about what parts of the message are signed
when decoding an in-line signature. My implementation for Alpine is as
well. Do you have any concrete examples of implementations that are not?

2. IME (that is, actually writing code to decrypt and verify e-mail
messages of both types) it's actually MIME that is way, way worse to
handle when it comes to wrapping, EOL canonicalization, etc. The various
implementations play very fast and loose with the "standards" here,
Apple being by far the worst culprit. Of course, that means little to
nothing to the average users, since their MUA should be able to handle
these messages.

Just to give you an example, my script to verify in-line signatures is
84 lines, and most of that is the setup (secure temporary directory,
error handling, etc.) and the text of the messages that the script
prints to indicate to the user what it's doing. The MIME equivalent has
basically the same setup cost, but it's 159 lines long. Almost all of
the difference is exception handling for MUAs that don't properly follow
the standards.

3. Your point that non-MIME messages can't do MIME is accurate, but
meaningless.

However, you're wrong that you cannot do signatures for attachments,
even with multiple attachments, with a message body signed in line.

I get that you have a preference, and personally I don't care how you
sign your messages. But as I stated before, it really bothers me when
the zealots (on either side) misrepresent the facts in order to bolster
their case.

Doug


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJU4WplAAoJEFzGhvEaGryEmWEIAIWaI2AjQfh/fXR4l7jUSBCn
1kJa7Bjgf27NwE+LHhhCjim72Cvdwf4aNNw52ZsuomOoU0clbe6CmK3sq3pDRvNP
RumZ4kaWf3TWkbRFBRhGj88hwx1zu4kE/NxfBnOv3oKrIsG9CpgdCRovjHOF/LMY
CxNXDE1mEdY19j8M+4OhXHIkq9F87DMJuz7j/keQu5b0Cn5P8IH8ek0wwx3m7egh
BAYq9pcNmlh5gBfT497MXmW3ZlENler8xjSoodcAuCvT4Ut5uLPM65ZLjQ1J69bJ
XcAEMCMUyjYwx2J1IIgroMQQdt9A34S/sVMsN9+jy/bx2Mx4CCdcvvOxbd9iMCI=
=p8CZ
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: empty-file-one.sig
Type: application/octet-stream
Size: 287 bytes
Desc: not available
URL: </pipermail/attachments/20150215/985ab0b0/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: empty-file-two.sig
Type: application/octet-stream
Size: 287 bytes
Desc: not available
URL: </pipermail/attachments/20150215/985ab0b0/attachment-0001.obj>