[messaging] Advertising public key in email (was: TOFU to ease PGP key discovery)

[Trevor Perrin]

[Mike Hearn wrote]:
>> The UI for this is terrible, but if you click the little tick symbol next to
>> "Signed" then it will open a certificate viewer and you can see the
>> certificate+fingerprint used to sign.

OK - I missed "Details" before, in OSX Mail I can see what's encrypted
and in a few clicks find a fingerprint.

That's not bad - It would be nice to see a "Johnny"-type study on
opportunistic S/MIME in modern clients.


[Tom Ritter wrote]:
>> A mail header certainly has the issue of a privacy-preserving way of
>> fetching it, but I find key attachments to be ugly and confusing to
>> non-users.  I feel like there must be some way in the MIME world to
>> stash a key somewhere that's hidden from clients but accessible to the
>> machine.

Stick the public key in a header?  If we're sending EC keys and not
trying to convey PGP key blobs, this is nothing (32 bytes).


[Mike Hearn wrote]:
>> But normally you want to authenticate after encryption, right? Otherwise
>> there can be odd attacks based on bit-flipping that can result in a message
>> that decrypts successfully but doesn't say what the sender thought they said.

There's a subtler reason you want to authenticate the ciphertext
*before* decrypting.  If  you don't do that, interaction of tampered
data with parsing code, prior to authentication, might leak info about
the rest of the plaintext through error messages or timing (a source
of TLS problems due to its MAC-then-Encrypt structure).

S/MIME and PGP commonly do authentication via signatures inside the
encryption (I believe the formats are flexible, but this is the common
approach).  PGP added the MDC, but it's still inside the encryption,
and as Andy points out there's a lot of processing after decryption
but before the MDC is checked (e.g. decompression).

So you don't want to expose PGP or S/MIME decryption errors or
decryption timings to untrusted parties.  (I don't know that anyone's
worked out the details, but there was some work on PGP as a decryption
oracle before MDC was added [1], and also using PGP's ad-hoc CFB
integrity check as an oracle [2]).


[Elijah wrote]:
>> There are a couple problems with the OpenPGP header. I could craft an
>> email that purports to be from trevp at trepv.net with an OpenPGP header of
>> my choosing. Maybe the recipient's client is smart and only accepts
>> OpenPGP header when the from header is DKIM signed. Even in this case,
>> both the sender's server and the recipient's server could inject a bogus
>> OpenPGP header.

OK, so it seems like your objection isn't the details of the OpenPGP
header, but with the *concept* of receiving a public key through email
and deciding to encrypt based on that.

So you're proposing to use the email header *not* to convey the public
key, but simply to indicate which of several other infrastructures to
query the key from (DANE? keybase? etc).

I don't totally get this - if you don't trust the email header to give
you a public key, why do you trust it to tell you where to look up the
public key?


[Dkg wrote]:
>> OpenPGP signatures currently don't contain the full public key or
>> even a full fingerprint.  What's present is the 64-bit "long keyid",
>> which i don't think is sufficient

Assuming the fetched public key has to verify the signature, the
forger has to solve two problems (match the 64-bit key ID and do a
"duplicate signature key selection").  I believe these are
individually possible, at least for RSA.  Whether it's feasible to
solve these simultaneously I don't know, someone would have to do the
math.


[David Gil wrote]:
>>  Using the same key for signing as for encryption gets vastly weaker
>>  security guarantees (i.e., Gap-DH for EC).

Depends, see [3].

Also, Gap-DH is a conventional assumption.  If it bugs you Strong-DH
can often be substituted, but people rarely bother.  If you were
thinking of [3] note that Gap-DH/ROM is used there for standard EC
encryption, it's not an artifact of combining encryption with
signatures.


Trevor

[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.25.3816
[2] https://eprint.iacr.org/2005/033.pdf
[3] https://eprint.iacr.org/2011/615