0

A little bit of background: I want to sign my emails for my own safety. None of my intended recipients are users of digital signatures. If one day someone were to impersonate me, I can prove my own identity, and disprove the identity of my impersonator.

I intend to use GPG to produce signatures for my emails. Right now, I am facing a dilemma on how to attach these signatures. Whether to use 'clearsign', 'detached signature', or just plain old 'sign'.

I will elaborate on my thought process, and the pros and cons I came up with, of each form of signatures.

Clear Signature

Pros:

  • No external program required to read messages
  • Verification can be done easily

Cons:

  • Intrusive and ugly headers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

some message
-----BEGIN PGP SIGNATURE-----

some signature
-----END PGP SIGNATURE-----

Detached Signature

Pros:

  • No external program required to read messages
  • No intrusive and ugly headers

Cons:

  • To verify messages, the content must be copied and formatted exactly like how it was when used to produce the signature. Reference here.

Normal Sign

Pros:

  • No intrusive and ugly headers

Cons:

  • Require an external program to read messages
  • Or the alternative is, to duplicate the content of the message. One for readability, and another that was baked in the signature, as produced by GPG.
  • When using the alternative, produces longer emails.
  • When using the alternative, to verify a message, one will need to compare the produced output from the baked content in the signature, and the duplicated plain content in the email.

If I were to resort to use 'clearsign', when my recipient don't have a clue in the purpose of digital signatures, the ugly headers will make my emails look unprofessional. I want to ensure any digital signature I attach to be as least intrusive as possible.

I could simply remove the headers. However, the process of verifying signatures becomes no less different than 'detached signature', although less error prone.

If I were to use just the normal 'sign' and duplicate the content for plain reading, in some cases, this procedure defeats the whole point of digital signatures through hashing and getting the fingerprint of the message.

What should I do? What's the norm of attaching signatures to emails? Are there other alternatives that I have yet to consider?

Desmond Rhodes
  • 3
  • 2
  • *"To verify messages, the content must be copied and formatted exactly like how it was when used to produce the signature."* - How is this a problem in your use case? In my opinion this is just a technical requirement, not really a problem. – Steffen Ullrich May 15 '21 at 08:21
  • @SteffenUllrich I believe this is a problem because in the process to verify, there is a lot of manual work that has to be done. And this invites opportunities for human error. I think verification should be handled with the least amount of intervention from people. – Desmond Rhodes May 15 '21 at 08:44
  • @SteffenUllrich Although, maybe I'm wrong. In terms of my use case, I could definitely set up some simple scripts to handle it. Thanks for pointing that out. – Desmond Rhodes May 15 '21 at 08:48
  • If there was a single standard way for doing this, there wouldn't be a problem. But there are many [standards](https://xkcd.com/927/). – Esa Jokinen May 15 '21 at 09:28
  • 1
    OP, do you send email from your own domain (e.g. yourname@yourdomain.tld)? If so, you might want to consider using DKIM to sign your messages. No ugly headers and verification is automatic by most MTA's. – mti2935 May 15 '21 at 11:41
  • @mti2935 Unfortunately no. Thanks for the suggestion though. I have not heard of DKIM before, and it has been a really good reading material so far. Will research some more into the matter. This might turn out to be a feasible alternative that I was looking for. – Desmond Rhodes May 15 '21 at 16:34
  • @DesmondRhodes That's great news. FYI, your goal of preventing others from impersonating you goes hand-in-hand with non-repudiation. In other words, verification of the signature implies that you and not someone else sent the message, but it also prevents you from later repudiating that you sent the message. See https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/ for some interesting reading on this subject. – mti2935 May 15 '21 at 17:11
  • @mti2935 I know that this is getting off topic from the main thread, but with GPG/PGP, wouldn't this problem be circumvented by simply revoking a signing key? Though I guess I will still be vulnerable if I'm still using Gmail. – Desmond Rhodes May 15 '21 at 17:45
  • OP, there are a few ways this could play out. Consider a scenario where you compose a message saying 'I agree to pay mti2935 $10,000 USD', then you sign the message with your GPG private key, and send me the message and the signature. Later, you want to get out of paying me $10,000, so you revoke your GPG key and repudiate that you sent this message to me . But still, the message was signed before you revoked the key... – mti2935 May 15 '21 at 18:06
  • Maybe I even have proof that the signed message existed before you revoked your key (by way of something like https://security.stackexchange.com/questions/220247/how-to-prove-you-created-ip-using-a-notary/220266#220266). In that case, how would you explain the signature? You could argue that the private key was compromised, and someone used the stolen private key to impersonate you and send a forged message purporting to be from you to me. But, that caveat exists with any cryptographic digital signature. – mti2935 May 15 '21 at 18:06
  • @mti2935 That makes sense. If this is something that I open myself to be vulnerable to, I believe the upsides outweighs the downsides, at the very least in my situation. Another tangent, it's funny that this lead to a somewhat similar question that I asked just moments ago in Law Stack Exchange [https://law.stackexchange.com/questions/65015/legally-binding-digital-signature](https://law.stackexchange.com/questions/65015/legally-binding-digital-signature). – Desmond Rhodes May 15 '21 at 18:41

1 Answers1

0

PGP/MIME (RFC 4880 and RFC 3156) is (in my humble opinion) the least intrusive way to PGP-sign mail. It puts the signature into an attachment of type application/pgp-signature using the filename signature.asc, which some email clients will be able to verify and others will at least recognize that it's a cryptographic signature.

However, if you control your server, you could consider using something more broadly adopted: DKIM and DMARC.

DKIM (DomainKeys Identified Mail, RFC 6376) signs your message body as well as several headers (typically From, Date, To, and Subject). Keys are served via DNS and signature verification is decently universal as this (alongside DMARC) is a key defense against spoofing attacks like phishing and Business Email Compromise (BEC).

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) sets a policy: what to do when an email fails to verify its DKIM signature (and is not permitted by SPF – you need an SPF record of v=spf1 ?all, denoting that SPF permits nothing, to effectively require DKIM). DMARC can instruct servers to quarantine or reject non-compliant mail. It also has reporting built in so you can observe what mail might be inappropriately blocked.

This ensures all mail sent by your server is cryptographically signed, that it's verified by nearly all recipients, and that you can instruct recipients to block or quarantine mail that isn't provably from you.

Community
  • 1
Adam Katz
  • 9,718
  • 2
  • 22
  • 44
  • Please notice that if you use SPF policy `v=spf1 -all` for the domain, you would have to use some other hostname as the *envelope sender*; otherwise the delivery fails. – Esa Jokinen May 21 '21 at 05:07
  • Oops, I meant to say `v=spf1 ?all` (now corrected), but no email system should be set up to deny delivery upon SPF failure. (SPF adoption has never had high enough efficacy to justify that.) – Adam Katz May 21 '21 at 15:02
  • If SPF is set to `-all`, that's certainly a justified reason for a *connection-stage rejection*. – Esa Jokinen May 21 '21 at 17:39
  • @EsaJokinen – I'm in anti-spam professionally and can tell you that SPF was designed for that concept but was not successful. Nobody SMTP-rejects on SPF failures. For public data, [here are the latest SpamAssassin net test results for SPF_FAIL](https://ruleqa.spamassassin.org/20210515-r1889913-n/SPF_FAIL), which show it hitting 2.1168% of the ham corpus. It's a fair spam signal, but not strong enough to independently convict a message. – Adam Katz May 21 '21 at 17:45
  • That's unfortunate, and might be the destiny of DMARC, too, because e.g. [Microsoft doesn't handle `p=reject` policies properly](https://security.stackexchange.com/questions/226270/enforcing-dmarc-policy-reject-on-an-office-365-tenant). – Esa Jokinen May 21 '21 at 19:13
  • Microsoft's stance at least allows downstream filters to block. Other systems out there just ignore it. A part of this is that even with the reporting mechanism in DMARC, there's still a lot of over-aggressive `p=reject` going on and people are too FP-adverse. That may change as BEC and phish get more prominent. – Adam Katz May 22 '21 at 18:27