

Inline PGP signatures considered harmful - pmoriarty
https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/

======
cperciva
Counterpoint: Mailing lists often break PGP/MIME, either by eating signature
attachments or by modifying the message text (e.g., by adding a mailing list
footer).

This is why FreeBSD consistently uses inline signatures for release and
security announcements -- it maximizes the probability that a message can be
validated.

~~~
jcrites
True. The email community ought to put more thought into the interaction
between email auth technology and email lists or email forwarding. Lists or
forwarding can break DKIM and DMARC, for example. Yahoo users ran into trouble
earlier this year when Yahoo enabled DMARC strict mode [1].

Idea: perhaps a way to allow forwarders to wrap existing content with a
header, footer, or quoting, such that the receiving client displays the parts
consecutively, but can reason about them independently. A bit conceptually
like iframes. Display the author of each part, perhaps with a visual lock and
boundary if signed.

On the other hand, there are adoption obstacles to introducing new email
technologies, similar to the obstacles to evolve HTTP / HTML. Furthermore,
email lacks as strong a steering leadership as browser vendors provide in the
website space, and the market is more fragmented than the browser market is
(varieties of webmail clients with differing display and validation
capabilities). Since sensitive information is sent through email less commonly
than through web browsers, there appears to be less demand and less genuine
interest in email security technology than website security technology, making
the adoption challenge for security technologies even harder. Although support
for SSL in email delivery is rising [2], most delivery connections are
protected by opportunustic TLS (which has many known weaknesses). A good
starting point would be a widely-adopted standard for receiving domains to
declare that they support TLS and perhaps pin their certificate, so that
senders can require TLS.

[1] [https://help.yahoo.com/kb/postmaster/yahoo-dmarc-policy-
sln2...](https://help.yahoo.com/kb/postmaster/yahoo-dmarc-policy-
sln24050.html)

[2]
[https://www.google.com/transparencyreport/saferemail/](https://www.google.com/transparencyreport/saferemail/)

~~~
kazinator
Mailing lists don't break DMARC: the stupid concept of DMARC breaks DMARC.

I had it going for a while and finally disabled it on my mail domain. It is
useless.

I'm not going to sit here collecting DMARC reports and fiddle with mail server
settings to set up exceptions for every damned mailing list so that I can one
day go into strict mode.

In the end it's good for only one thing: helping to police activities between
pairs parties (A and B) not related to me, with my only involvement (non-
involvement, really!) being that one of them, B, is misusing my domain name
(in a From: header) to write e-mail to A.

I've decided that I don't give a crap about that, and will return to
concentrating on filtering spam that actually comes my way. If an actual
working e-mail address in my domain is spoofed, and it generates a back-
scatter reply from the victim of the spoof that is received in my domain, I
will deal with that. What happens between A and B not affecting me in any way
isn't my problem.

~~~
jcrites
DMARC helps you most in two situations: (1) you're a person or organization
with an Internet presence that's crucial to you, where it's especially harmful
for spammers or phishers to trick people by impersonating you (2) You're on
the receiving end of the attack.

If I recall correctly, PayPal helped put DMARC together since large numbers of
their customers were being phished. "More than 25 million email messages
spoofing PayPal were rejected during the 2013 holiday buying season" according
to the DMARC site.

I agree that it may not be worth the bother to enable DMARC until there's a
lot at stake when protecting your domain. SPF is easier to set up, offers
reasonable protection, and is widely adopted. DMARC's best value comes from
helping to protect large, important domains, for whom intelligence about
impersonation attacks or misconfigurations can be valuable. For the domains
that I've helped protect I think DMARC has been worthwhile.

It's also true that DMARC breaks compatibility with common email use-cases
like forwarding. However, if we are to move forward in email security, it
can't remain possible for every person to originate email claiming to be
anyone else, which is what email lists and forwarding do in some cases.

We need a sensible way to take a message from Bob, validly signed by Bob, and
wrap it so that I can send it on to you, perhaps with some added content at
the beginning and end, or quoted, and additionally signed by me; so that you
know the part claimed to be from Bob is really from Bob; and you know that I
really forwarded it and wrapped it with my content. If we could solve the
forwarding use-cases, I think that would remove the primary bottleneck to
adoption.

The minimal bar to setting up DMARC is not high. The monitoring features are
optional. A minimal DMARC setup is a policy saying that email from your domain
will be authorized by SPF or a DKIM signature; a DNS record with this
statement enables receivers to drop email lacking these proofs of legitimacy.

Did you know that SMTP includes no provision to determine whether a sender is
allowed to send email from a domain? All anti-impersonation authorization
logic has been bolted on later through protocols like SPF, SenderID, DKIM, and
DMARC. DMARC is the first protocol to achieve meaningful adoption that
protects the "From" address that you see in email clients from impersonation.
DMARC is consequently the first protocol to provide an actual guarantee for
receivers of the authenticity and integrity of email sent from your domain.
Anti-spam systems predominately work around the lack of widespread adoption of
these capabilities by correlating lots of factors; I suspect anti-spam would
be slightly easier if strong domain-level message authenticity was common (for
whitelisting if not blacklisting).

Email could use an evolution in a similar fashion to the recent standard
updates for HTTP and HTML.

~~~
kazinator
The information in your paragraph should be the first thing explained on
dmarc.org in a FAQ item about who shouldn't bother publishing DMARC.

> _We need a sensible way to take a message from Bob, validly signed by Bob,
> and wrap it so that I can send it on to you, perhaps with some added content
> at the beginning and end, or quoted, and additionally signed by me; so that
> you know the part claimed to be from Bob is really from Bob; and you know
> that I really forwarded it and wrapped it with my content. If we could solve
> the forwarding use-cases, I think that would remove the primary bottleneck
> to adoption._

Here is a system that blows away DMARC.

Let's have a DNS record, similar to DMARC's, which is keyed on the From:
domain in the same way.

This DNS record provides a URL template. The verifier inserts an item taken
from the e-mail into this template and performs a query on the URL. The URL
responds with a 200 OK or an error.

What item is inserted into the URL template? A special token which is added to
the e-mail by the originating domain in a special header.

This token is a 128 bit number (say). It can be completely random, or it can
be a cookie of some kind. What it isn't: it's not a hash over the whole
message. Basically what it means is up to the domain. It could contain a
crypto hash over some selected headers. (The URL could include a few important
headers as URL parameters, like From: and Date: to help the server: and the
template language for the URL could be flexible so that the publisher can
decide what headers they need in addition to the special token.)

To publish this protection mechanism, your just need this DNS record, a server
for the URLs and your mail software to add the tokens to messages.

An example implementation of tokens would be: generate a random 128 bit
number, and store it in a cache that expires in one week. The server just
checks whether the number is in that cache.

Numbers which are not validated in any way against headers and whatnot could
be replayed by an attacker spoofing your domain. (The attacker receives a
legitimate mail, and then uses the token to generate a fake one.)

Protection against this would be: 1) mix information about the additional
headers into the token; don't just make it random, and then request these
headers in the URL template and check. 2) expire the tokens in a timely way:
don't certify stale tokens more than N days old for some reasonably small N.
3) detect abuses of a token, like too many lookups: your mail is not expected
to go through 20 hops, so 20 hits on a token is suspicious, right?

------
zobzu
"People often suggest that inline PGP signatures in e-mail are somehow more
compatible or more acceptable than using PGP/MIME. This is a mistake. Inline
PGP signatures are prone to several failure modes, up to and including
undetectable message tampering."

Nope. it IS more compatible. With old clients, etc.

That's confusing being more compatible and being safer. That's not the same
thing.

~~~
brute
I want to second that. I switched from PGP/MIME to inline PGP a while ago,
since multiple of my contacts complained about troubles reading mails.

K-9 on android does not have support for PGP/MIME, probably wont have it for
the time to come as it requires fundamental changes in the way the program
stores the mails. There doesn't seem to be any open-source mail app on android
that can handle PGP/MIME (correct me if I am wrong, I really like to know)

Windows Mail displays the mail's content as an attached text file, which is
quite inconvenient.

On the plus side, several web clients I have encountered are now able to
handle it. So there is hope.

~~~
dingdingdang
> On the plus side, several web clients I have encountered are now able to
> handle it. So there is hope.

Handle PGP/MIME or inline PGP? Which web clients? Thanks.

~~~
brute
One webclient that handles it well is roundcube
([http://roundcube.net/](http://roundcube.net/)). Others I have seen are the
web interfaces of mail providers (i.e. posteo.de), which deploy their own
webmail software, or strip all attribution from the user interface.

To be clear: I am talking of displaying a PGP/MIME mail correctly. I am not
talking about verifying a signature or composing a signed/encrypted mail
(which you probably shouldn't do in a web client anyway). Inline PGP is
neither parsed nor recognized.

------
irremediable
To be honest, the only one of these that grabbed my attention was "Message
tampering through header substitution". But in practice, I doubt it's going to
be a problem.

Offtopic: is anyone else getting sick of the "x considered harmful" formula?
It sounds smug, and usually entitles an article that disparages innocuous
technologies.

~~~
greatzebu
See "Considered Harmful Essays Considered Harmful"
([http://meyerweb.com/eric/comment/chech.html](http://meyerweb.com/eric/comment/chech.html))

"We should stop doing X" will always be a popular essay topic, but the "X
Considered Harmful" framing is a bit stale at this point.

~~~
irremediable
Haha. Thanks for the link. This sums it up well.

I especially love the closing sentence.

 _Finally, I’d especially like to thank all the people who wrote “considered
harmful” essays over the last few years. Without the degree of annoyance you
collectively created, I might never have bothered to write this essay._

------
zenkius
To PGP/MIME or not to PGP/MIME

TL;DR: PGP/MIME has some serious flaws. I propose specifying an alternative
method for PGP-encrypting e-mail (including attachments) which improves
security while being backwards compatible with legacy ad-hoc PGP encryption,
air-gaps and webmail plugins.

[https://www.mailpile.is/blog/2014-11-21_To_PGP_MIME_Or_Not.h...](https://www.mailpile.is/blog/2014-11-21_To_PGP_MIME_Or_Not.html)

------
Harkins
I won't dispute any of the article's technical points, and I once used
attached signatures for similar reasons.

But I will point out that attached signatures are unusable because you get
never-ending replies from people asking what the file you attached is, why
can't they open it, is it a virus, did it cause this computer problem of
theirs, etc. Yes, theoretically there will one day be sufficiently clever
email clients, but it's been something like twenty years and there has been
nearly zero progress.

With inline signatures I could add a comment that said "If you don't know what
this is, it's OK to ignore it".

Technical merits are meaningless if human factors make a security feature too
confusing or hard to use. For proof of this, run 'man gpg' and then look at
what percent of your inbox is signed/encrypted.

------
fdik
There is no way to do PGP/MIME with Microsoft Outlook, because it's not
possible to set a MIME type for the message body.

Therefore, on this platform we have no other choice, and while Microsoft
doesn't fix that, there will be inline-PGP (and PGP proprietary format for
HTML).

------
lucb1e
Neither of the examples actually validate for me, both give a bad signature.
Not sure if they are supposed to work, but it seems so.

