[openpgp] Intended Recipient Fingerprint signature subpacket

[Vincent Breitmoser]

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

[v***@nym.hush.com]

Post by Vincent Breitmoser
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.

======

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

[Vincent Breitmoser]

Post by v***@nym.hush.com
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.

Post by v***@nym.hush.com
=====[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.

Post by v***@nym.hush.com
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

[Vincent Breitmoser]

No feedback on this at all? Should I maybe create a website and logo for
a surreptitious forwarding attack?

I'll add some more motivation: There is currently no way to distinguish
signatures made for plaintext messages from signatures made for encrypted
messages.

This opens up a scenario where a message is sent as signed cleartext (which many
people do by default), and only encrypted at a later point, for example by an
inbound message encryption feature. At that point, there is no way for a mail
client to tell whether this was actually an e2e encrypted message, or sent in
the clear.

As a straightforward fix, I propose an additional "sent in the clear" subpacket
that indicates when a signature was made over a message that is sent in the
clear, and wasn't intended to authenticate an encrypted message.

- V

Post by Vincent Breitmoser
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

[Salz, Rich]

You might find it interesting to look at a paper by Don Davis, "Compliance Defects in Public-key cryptography."

[Vincent Breitmoser]

Post by Salz, Rich
You might find it interesting to look at a paper by Don Davis, "Compliance
Defects in Public-key cryptography."

I looked it up, but I don't really see the connection. Can you elaborate on
this?

- V