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

Bernhard Reiter bernhard at intevation.de
Mon Feb 12 10:31:37 CET 2018


Am Freitag 02 Februar 2018 18:48:08 schrieb Daniel Kahn Gillmor:
> 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

from briefly reading over the issue I think that "inherent metadata leak"
is too broad a term to represent the security pros and cons well enough.

Just sending an email or a webpage will also inherently leak meta data
for someone listening on the line. So you'll certainly won't disable begin 
able to send those as well.

> 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.

Users might also object to the higher exposure to revoked certificates
and a more surprising behaviour deviating from the CMS standards (which as far 
as I know mandate checking the validity of certs).

It comes down to post some trust into the implementations and the certificate 
authorities you chose to use. I think we'd do more for users if we educate 
them about some of the more basic properties.

Best Regards,

www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180212/e5986529/attachment.sig>

More information about the Gnupg-devel mailing list