[gmime-devel] avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG

[Jeffrey Stedfast]

Hi Daniel & GnuPG devs,

On 2/2/2018 12:48 PM, Daniel Kahn Gillmor wrote:
> Hi GMime and GnuPG developers--
>
> sorry for the cross-posting!  coordinating this kind of thing
> cross-project is tough.
>
> I recently learned that default handling of signed S/MIME mail with
> GnuPG causes an inherent metadata leak about the user's activity:
>
>      https://dev.gnupg.org/T3348#110132
>
> As a MUA developer, I'd like my MUA to simply handle as much crypto as
> it can on the user's behalf automatically, correctly and silently,
> without needing any special configuration or asking the user to make any
> tough tradeoffs that they might object to.
>
> What kinds of tradeoffs are objectionable?  Performance tradeoffs are
> probably OK, since they're user-visible, and can be mitigated by
> disabling crypto.  But metadata leakage by default seems really
> problematic, because (a) it is invisible to the user, and (b) once done,
> it cannot be undone.
>
> So my question for GMime and GnuPG developers is how a MUA that uses
> GMime should approach this.  Given that GMime relies on GnuPG, and GnuPG
> basically says "if you process S/MIME mail, you'll leak metadata", what
> is the best way to instruct GMime to say "handle as much cryptographic
> mail as you can without leaking metadata"?
>
> GMime 3 has greatly simplified its crypto handling interface, and it has
> moved fully to GPGME on the backend, which i appreciate.  However, i
> think the interface is now so clean that i don't know how to either:
>
>   * tell GMime to disable crl checks

I'd be willing to add an API to disable CRL checks if there's a way I 
can pass that along to gpgme.

>
> or
>
>   * tell GMime not to verify S/MIME signatures at all

Willing to add an API for this as well (although I guess it's not 
necessary if an API to disable CRL checks is added?)

>
> Either of these methods would address the default metadata leakage
> concern, but the first choice provides more functionality to the user.
>
> i note that GPGME offers gpgme_set_offline(), which tells it to avoid
> talking to the network entirely.  Maybe that can be exposed by GMime
> somehow?

Absolutely.

>
> i don't think invoking gpgme_set_offline(true) would break other uses of
> GPGME inside GMime or any other sensible MUA, but if there's a fear that
> it does, i'd like to hear about it.

Well, I suppose that, like S/MIME signature verification, it would also 
disable PGP key-server lookups?

It might be best if there was a way to disable CRL checks on a per 
gpgme_ctx_t basis as opposed to globally, but I can have GMime use the 
global option until such an option exists (note: might be racey if you 
try and verify signatures on multiple threads).

I'll wait for the GnuPG/GPGME devs to comment before making changes to 
GMime.

Jeff