[messaging] alternative to OpenPGP?

[Trevor Perrin]

On Mon, Aug 17, 2015 at 4:24 AM, Peter Gutmann
<pgut001 at cs.auckland.ac.nz> wrote:
> Trevor Perrin <trevp at trevp.net> writes:
>
>>Another thing to be careful about with (PGP, S/MIME, JOSE, XML-Security) is
>>that it's up to you to compose public-key signing and public-key encryption.
>>It's not always easy to figure out whether to sign-then-encrypt or encrypt-
>>then-sign, and what other checks to add.
>
> CMS (so S/MIME) at least gets this right, its authenticated-encryption mode
> uses encrypt-then-MAC, and also MACs metadata to protect that.

I'm not sure.  According to [1], the "general simple solution" for
layering signing and encryption is:
 "1. Whenever encrypting something, include the identity of the sender"
 "2. Whenever signing something, include the identity of the receiver"

I think you're referring above to RFC 5083's optional originatorInfo,
which can be used for (1).  But I don't think the CMS SignedData has a
standard way to bind the recipient (2).

So when Bob receives a signed-then-encrypted CMS message from Alice,
there's no cryptographic verification that Alice intended to send the
message to Bob.  Maybe she sent it Charlie, who re-encrypted it to
Bob.  This is Don Davis' "surreptitious forwarding" [2].

I think S/MIME tried to fix that (RFC 3581) by allowing a full MIME
message, with its headers, to be included inside the signing layer.
But `it is up to the receiving client to decide how to present these
"inner" headers along with the unprotected "outer" headers`.

Apparently this was problematic due to implementation variance, as
well as modification of the outer headers by intermediaries.  There
was some IETF work in 2007-2009 on this which didn't go anywhere [3],
and there's some recent IETF work on same topic [4].  Some PGP people
have started looking into something similar (under the term "Memory
hole" [5]).

Maybe tackling the problem of header protection in such generality has
held up the email case.  But I also think this a good example of
independent signature and encryption layers that application-protocol
designers have to compose as an anti-pattern.

As far as fixing things, I'd advocate for at least explicitly binding
both parties' public keys as identity info, since this can be done
easily in an integrated crypto layer, and also helps against MITM
attacks.


Trevor


[1] https://www.iacr.org/archive/eurocrypt2002/23320080/adr.pdf
[2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html
[3] https://tools.ietf.org/html/draft-liao-smimeheaderprotect-05
[4] https://tools.ietf.org/html/draft-melnikov-smime-header-signing-01
[5] https://modernpgp.org/memoryhole/