Inline PGP signatures considered harmful
dkg.fifthhorseman.net
dkg.fifthhorseman.net
This is why FreeBSD consistently uses inline signatures for release and security announcements -- it maximizes the probability that a message can be validated.
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...
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.
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.
> 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?
That's not "breaking", that's PGP working as designed. The message has been modified from what the sender sent, and so the signature no longer matches, and you can tell it has been changed.
Nope. it IS more compatible. With old clients, etc.
That's confusing being more compatible and being safer. That's not the same thing.
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.
Handle PGP/MIME or inline PGP? Which web clients? Thanks.
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.
Offtopic: is anyone else getting sick of the "x considered harmful" formula? It sounds smug, and usually entitles an article that disparages innocuous technologies.
"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.
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.
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...
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.
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).