Subject: [openpgp] Intended Recipient Fingerprint signature subpacket

From: Vincent Breitmoser <[email-masked]>
Date: Tue, 6 Mar 2018 00:19:51 +0100

Hey folks,

dkg and I have been discussing an "Intended Recipient Fingerprint"
subpacket, that pins a signature to be valid only in an encrypted
context to the indicated recipient.

Use of this subpacket removes some wiggling room for signed+encrypted
messages.  This can be used to prevent replay attacks, where a signature
is taken out of its context and forwarded to a different recipient.

Please see https://0xacab.org/schleuder/schleuder/issues/158 for a
complete description of an attack scenario in the context of the
Schleuder remailer.  The given scenario is solved with this subpacket on
the openpgp layer.

Diff attached for rfc4880bis, please comment.

 - V

diff --git a/middle.mkd b/middle.mkd
index f09d85f..373aca2 100644
--- a/middle.mkd
+++ b/middle.mkd
@@ -1058,6 +1058,7 @@ The value of the subpacket type octet may be:
           32   Embedded Signature
           33   Issuer Fingerprint
           34   Preferred AEAD Algorithms
+          35   Intended Recipient Fingerprint
   100 to 110   Private or experimental
 
 An implementation SHOULD ignore any subpacket of a type that it does
@@ -1662,6 +1663,19 @@ signature, the key ID of the Issuer subpacket MUST match the low
 Note that the length N of the fingerprint for a version 4 key is 20
 octets; for a version 5 key N is 32.
 
+#### Intended Recipient Fingerprint
+
+(1 octet key version number, N octets of fingerprint)
+
+The OpenPGP Key fingerprint of the intended recipient primary key.  If
+one or more subpackets of this type are included in a signature, it
+SHOULD be considered valid only in an encrypted context, where the key
+it was encrypted to is one of the indicated primary keys, or one of
+their subkeys.  This can be used to prevent forwarding a signature
+outside of its intended, encrypted context.
+
+Note that the length N of the fingerprint for a version 4 key is 20
+octets; for a version 5 key N is 32.
 
 ### {5.2.4} Computing Signatures

---

From: [email-masked]
Date: Mon, 05 Mar 2018 23:09:27 -0500

>is taken out of its context and forwarded to a different recipient.

======

In principle, it's a good idea.

But, the attacker could still send it along as a clearsigned message, and if the recipient accepts the message at face value, the attack succeeds.

There is really no substitute for fixing this in the context of the message itself.  Anything signed, should mention the person addressed in the text of the message.

Example:

message [1]

=====[begin text of message to be signed and encrypted to Bob]=====

Hi Bob,

Thanks for everything!

Love,

Alice

=====[end text of message to be signed and encrypted to Bob]=====

as opposed to this,

message [2]:

=====[begin text of message to be signed and encrypted to Bob]=====

Thanks for everything!

Love,

Alice

=====[end text of message to be signed and encrypted to Bob]=====

If at some later time, Bob and Alice had a falling out, Bob could send the second message to John, (a not so good friend of Alice). who now thinks Alice 'loves' him.

Bob could obviously never do this with the first message in the above example.

Again, more of an issue to be put in an advisory caution in the new rfc, rather than designing a new packet,  but if the new packet is easy to implement, then great.

vedaal

---

From: Vincent Breitmoser <[email-masked]>
Date: Tue, 6 Mar 2018 09:46:25 +0100

> But, the attacker could still send it along as a clearsigned message,
> and if the recipient accepts the message at face value, the attack
> succeeds.

That's correct. It *would* be possible to use the same subpacket even in
a cleartext context, but that is a much less clear-cut use case that is
more difficult to reason about, and easy to mess up in implementation.

> =====[begin text of message to be signed and encrypted to Bob]=====

By your other description, I assume you mean clearsigned messages here?

For encrypted messages, the attack will fail: Bob can't forward a
signed+encrypted message of Alice's to John and trick him into thinking
it was intended for him, since the signature does say it was meant for
Bob.

> if the new packet is easy to implement, then great.

For a typical workflow, it's very easy to implement. If you consider an
api that is roughly:

signAndEncryptTo(cleartext, signingKey, recipientKeys) -> ciphertext
decryptAndVerify(ciphertext, decryptionKey) -> verificationstatus, cleartext

then it works transparently from an api user perspective, and uses only
information that is readily available in the implementation for an
additional error case.

 - V