Subject: [openpgp] signed/encrypted emails vs unsigned/unencrypted headers

From: Ximin Luo <[email-masked]>
Date: Wed, 03 Jul 2013 00:22:26 +0100

To [email-masked],

As per [1] and [2], sign-then-encrypt is only really secure as long as you do
it on *all* the information that forms the message, some of which might be
external to the message data itself. Crucially, this includes the recipient.

What's the current status of this in the PGP/MIME standard? Is it still a
problem? I notice that email subject headers are in a similar situation, and
users have complained about it.[3] The problem of unencrypted/unauthenticated
recipient is less obvious, so I haven't seen user complaints, but potentially
it is more serious.

Although not explicitly mentioned in the previous citations, these are
conceptually the same problem - i.e. you are only executing sign-then-encrypt
on *part* of the data that should be secured. So, I believe that it's possible
to work towards a single clean solution that fixes both problems.

(Sorry if this has been asked before already, or if the problem has already
been fixed; I did check the list archives but couldn't find anything on a quick
scan, nor a quick session of web searching.)

X

[1]
http://crypto.stackexchange.com/questions/5458/should-we-sign-then-encrypt-or-encrypt-then-sign
[2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html#CITEpgp
[3] http://www.mozilla-enigmail.org/forum/viewtopic.php?f=9&t=328

-- 
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0

---

From: Ximin Luo <[email-masked]>
Date: Tue, 16 Jul 2013 09:06:08 +0100

comments, anyone?

On 03/07/13 00:22, Ximin Luo wrote:
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>

---

From: Werner Koch <[email-masked]>
Date: Tue, 16 Jul 2013 10:16:05 +0200

>> recipient is less obvious, so I haven't seen user complaints, but potentially

There is a simple and standard conform way to tackle this:
message/rfc822 - all covered by PGP/MIME.

FWIW, PGP/MIME allows you to do encrypt-then-sign or any other
combination - if you really want that.  PGP/MIME is a well thought out
and matured system created 17 years ago.

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Ximin Luo <[email-masked]>
Date: Tue, 16 Jul 2013 09:28:50 +0100

> and matured system created 17 years ago.

Thanks, I will take a look.

Could you take a guess on why this feature is not used more? I haven't seen any
emails that use it (either an encrypted To: or Subject: field), either because
no emails actually use it, or perhaps it's my client's fault for not displaying
it correctly.

As mentioned in a previous link, it includes a security issue due to
surreptitious forwarding of signed messages to unintended recipients. So I
would've thought people writing these PGP email clients would've taken it into
account.

X

---

From: Werner Koch <[email-masked]>
Date: Tue, 16 Jul 2013 12:01:21 +0200

> Could you take a guess on why this feature is not used more? I haven't seen any

The first question should be, why OpenPGP is not used more.  The subject
fulfills an important task: It allows to quickly sort and order
messages.  An encrypted subject would require that you decrypt all
messages even if you are not interested in them.  Further, support for
arbitrary nested MIME structures seems to be broken in some MUAs.

Salam-Shalom,

   Werner

p.s.
What I do is to use a nonsense subject line for encrypted messages.  This
helps to remember the context of a mail thread while not revealing the
content of the conversation.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 16 Jul 2013 12:31:54 +0100

> recipient is less obvious, so I haven't seen user complaints, but potentially

Not clear why this is an issue? Surely the fact the message is
encrypted to the recipient is sufficient?

---

From: Ximin Luo <[email-masked]>
Date: Tue, 16 Jul 2013 22:49:48 +0100

> encrypted to the recipient is sufficient?

The signed part does not explicit say who the recipient is. When the initial recipient decrypts the message, they remove this implicit information (the intended recipient). They are then free to encrypt the signed message to a different, *unintended*, recipient. (See [2] I linked previously.)

It is possible that I missed something, that PGP sign+encrypt actually does already implicitly add this information to the inner signed (non-forgeable) data. But this is not consistent with my research - I do not see anything in RFC 4880 that would prevent the attack described. I haven't read it in full, so I could be wrong, but the sources I cited previously agree with this, and that's why I emailed this list about it. Please correct me if I am wrong!

X

P.S. The GnuPG CLI does not let you decrypt a sign+encrypted file, without also verifying the signature. So, I hoped that it was actually transparently adding the list of encryption recipients to the inner signed data. However this appears not to be the case, which means in theory someone could write a tool to do the surreptitious forwarding attack. I did an experiment, using "a.txt" containing 6 bytes "12345\n". Let's see the results:

# Signed and encrypted data, using gpg --sign --encrypt
$ gpg --list-packets a.txt.siggpg
:pubkey enc packet: version 3, algo 1, keyid 68AE6913E59091EC
	data: [2048 bits]
:encrypted data packet:
	length: unknown
	mdc_method: 2
:compressed packet: algo=2
:onepass_sig packet: keyid 860DEF3B8F650B79
	version 3, sigclass 0x00, digest 8, pubkey 1, last=1
:literal data packet:
	mode b (62), created 1373995055, name="",
	raw data: 6 bytes
:signature packet: algo 1, keyid 860DEF3B8F650B79
	version 4, created 1373995055, md5len 0, sigclass 0x00
	digest algo 8, begin of digest de 4e
	hashed subpkt 2 len 4 (sig created 2013-07-16)
	subpkt 16 len 8 (issuer key ID 860DEF3B8F650B79)
	data: [4096 bits]

None of the inner decrypted packets contain any To: information about any encryption recipients
- onepass_sig http://tools.ietf.org/html/rfc4880#section-5.4
- literal data (6 bytes cannot possibly contain To: info)
- signature packet, version 4 http://tools.ietf.org/html/rfc4880#section-5.2.3

For more evidence, compare this to a non-encrypted signed file, of the same data. The signature-relevant packets are the same in both the encrypted/cleartext versions, and contain no additional information on the encryption recipient.

# Signed clear data, using gpg --sign
$ gpg --list-packets a.txt.sig
:compressed packet: algo=1
:onepass_sig packet: keyid 860DEF3B8F650B79
	version 3, sigclass 0x00, digest 8, pubkey 1, last=1
:literal data packet:
	mode b (62), created 1373994966, name="",
	raw data: 6 bytes
:signature packet: algo 1, keyid 860DEF3B8F650B79
	version 4, created 1373994966, md5len 0, sigclass 0x00
	digest algo 8, begin of digest ef 3a
	hashed subpkt 2 len 4 (sig created 2013-07-16)
	subpkt 16 len 8 (issuer key ID 860DEF3B8F650B79)
	data: [4095 bits]

---

From: Ximin Luo <[email-masked]>
Date: Tue, 16 Jul 2013 23:05:11 +0100

> arbitrary nested MIME structures seems to be broken in some MUAs.

I think those are separate questions. :p

Your argument about "would require decrypt" is not tight; it applies equally to the message contents ("you can't search yada"). This is a trade-security-for-convenience approach, which is asking for trouble even if you can't explicitly think of an attack.

For maximum security, all headers that have end-to-end semantics should be added to the signed part of the message, and only the subset of these that are actually necessary for email to work correctly, should be sent in the clear.

For example, one could imagine an attack where you have 1000 messages in a thread with 10 people, then you could infer from the plaintext References: headers, a prediction on which of these 10 people are closely connected with each other. You can attack the plaintext To: header as I described in a previous post, and perhaps you can similarly attack the Subject: header even though right now it *seems* unimportant. A future application may use email transport in a novel way and treat the Subject: header to have much more valuable semantic meaning that affects application logic, wrongly assuming that PGP sign+encrypt is "secure" in that area.

X
 
> content of the conversation.
」

---

From: Werner Koch <[email-masked]>
Date: Wed, 17 Jul 2013 09:45:35 +0200

On Wed, 17 Jul 2013 00:05, [email-masked] said:

> Your argument about "would require decrypt" is not tight; it applies
> equally to the message contents ("you can't search yada"). This is a

No, it does not.  Stepping users of webmail aside, most people are using
IMAP and not POP3 or UUCP.  With IMAP you download the headers
(including the subject) and only then select which mails to read and
finally download.  Yes, this makes a difference if you think about
businesses with multi-megabyte PDF documents.

In any case, this is not relevant to the OpenPGP standard and thus you
may want to move this discussion to another list.  FWIW, S/MIME has the
very same semantics.

Salam-Shalom,

   Werner

---

From: Ximin Luo <[email-masked]>
Date: Wed, 17 Jul 2013 09:01:33 +0100

> businesses with multi-megabyte PDF documents.

I don't see how this is significant - is it such a conceptual stretch to
imagine headers and the body being encrypted separately? Or do you mean that
RFC 822 does not support this?

> may want to move this discussion to another list.  FWIW, S/MIME has the

Which mailing list, then? pgp-mime has been shut down and redirected to this
one: http://www.imc.org/ietf-pgp-mime/

X

---

From: Werner Koch <[email-masked]>
Date: Wed, 17 Jul 2013 11:29:47 +0200

> RFC 822 does not support this?

MIME supports this.  But it does not care about the outer header.
Partly because it carries the meta data required for parsing MIME.

If you like to encrypt the subject, you may simply use a single line
base64 encoding of the an OpenPGP encrypted message.  But there are
problems.  Imagine that you need to encrypt to several recipients with
the resulting line extending to over 989 characters - which violates
rfc822.

> Which mailing list, then? pgp-mime has been shut down and redirected to this

Feel free to use the gnupg-users list.  Over the years this kind of
ideas have been discussed there several time.  Or any other MUA related
list.

Shalom-Salam,

   Werner

---

From: Ben Laurie <[email-masked]>
Date: Wed, 17 Jul 2013 10:43:20 +0100

> The signed part does not explicit say who the recipient is. When the initial recipient decrypts the message, they remove this implicit information (the intended recipient). They are then free to en…

Ah, I see. I am sure I remember this being discussed before. But I
can't remember where.

> It is possible that I missed something, that PGP sign+encrypt actually does already implicitly add this information to the inner signed (non-forgeable) data. But this is not consistent with my rese…

I'm not sure what you think the attack is. I get that you end up with
a signed blob that is sent to someone other than the intended
recipient. So what?

You might find sections 3 and 4 of
http://www.apache-ssl.org/tech-legal.pdf helpful.

---

From: Ximin Luo <[email-masked]>
Date: Wed, 17 Jul 2013 19:27:40 +0100

> http://www.apache-ssl.org/tech-legal.pdf helpful.

As per [2], if I ever sign a message consisting of "yes" or "no" or some other short message with very little context, the attacker (whom I encrypted the signed message to) could use this signed message in some other context, fooling people that I said something I didn't. One might argue "how unlikely", but it's still an unnecessary caveat (i.e. complexity) in using encrypted email, which will confuse people not familiar with the details.

My original point was that this attack is a specific example of a general design flaw in encrypted email - i.e. unsigned/unencrypted headers.

I'm not concerned that some legal principle clears me of responsibility; practical objective security should not be dependant on the efficiency or subjective justice of any legal system. I would much rather the attack not be possible in the first place.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 17 Jul 2013 15:06:06 -0400

> My original point was that this attack is a specific example of a general design flaw in encrypted email - i.e. unsigned/unencrypted headers.

the attack you're describing above has nothing to do with encryption; it
has to do with signatures.

This is a fundamental vulnerability of any system that involves signed
data that is dependent for interpretation on unsigned context.  This is
also the case for (e.g.) clearsigned plain text files.

It sounds to me like you're proposing a way that some additional context
could be automatically signed by compatible mail user agents.  I think
this is a fine idea, though i think it needs more detail than what has
been sketched out here thus far.  For example, what should a compatible
MUA do if the signed message contains a signed copy of a header which
doesn't match the unsigned header of the message in question?  what if a
signed message contains two sets of signed headers that conflict with
each other?  how should an MUA represent the idea that headers are
signed?  and so forth...

it also sounds like it would be relevant for other e-mail signature
standards too, since S/MIME (for example) might want the same sort of
protection.  This makes it out of scope for the current mailing list,
since it isn't OpenPGP specific.

Werner already suggested that [email-masked] might be a
reasonable place to have this more general discussion.  Maybe followup
should happen over there?

Regards,

	--dkg

---

From: Ximin Luo <[email-masked]>
Date: Wed, 17 Jul 2013 20:42:18 +0100

> also the case for (e.g.) clearsigned plain text files.

It is *mostly* to do with signatures yes, but encryption does play a part - it adds the implicit *non-signed* information that the data is a message TO someone. (Although I take your point, a signed non-encrypted email also has this implicit metadata, and is vulnerable too.) If you signed a self-contained plain text file, this is not necessarily the case.

> should happen over there?

Good points and yes, I will take this discussion there.

Thanks for all the info and comments everyone!