Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Rob Browning]

[If possible, please preserve the 745553-forwarded address in any replies.]

This bug was filed recently, and I suspect it might be something you'd
like to discuss upstream.

Thanks

Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

> Package: emacs24-el
> Version: 24.3+1-2
> Severity: normal
>
> Hi emacs maintainers!
>
> in 
>
> /usr/share/emacs/24.3/lisp/gnus/mml2015.el.gz
>
> i see this variable definition:
>
> (defcustom mml2015-always-trust t
>   "If t, GnuPG skip key validation on encryption."
>   :group 'mime-security
>   :type 'boolean)
>
> This is a security risk for users of encrypted mail.  i believe it
> should be set to nil by default.
>
> Here's why:
>
> Consider Alice, who has OpenPGP certificates for "Bob
> <bob@example.org>" and "Carol <carol@example.org>" in her keyring (in
> that order).  She has certified them both, so there is one valid
> primary key for bob@example.org and one valid primary key for
> alice@example.org.
>
> Bob turns evil (or maybe his key is compromised) and he adds a new
> User ID: "Bob <carol@example.org>" to his OpenPGP cert.  He publishes
> the update to the keyservers.
>
> Alice, following best practices, updates her keyring from the
> keyservers regularly.
>
> Alice's keyring now has two certs that have a "carol@example.org" user
> ID in them.  One of them is valid, and the other one is not.
>
> Alice now composes a message to "Carol <carol@example.org>" and marks
> it with:
>
>  <#secure method=pgpmime mode=signencrypt>
>
> As the message goes out, mml-mode just passes the e-mail address
> carol@example.org to gpg to encrypt the message body, and gpg uses the
> e-mail address to select a key.  Since Bob's key is first in the
> keyring, it is the one that will be used.
>
> Bob then sneaks a peak at Carol's e-mail (maybe they're delivered to the
> same server, or he has a machine on the same network), catches the
> message in transit, and can decrypt the content, violating Alice's
> message confidentiality expectations.
>
> Please set mml2015-always-trust to default to "nil" instead of "t".
>
>         --dkg
>
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (200, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages emacs24-el depends on:
> ii  emacs24-common  24.3+1-2
>
> emacs24-el recommends no packages.
>
> emacs24-el suggests no packages.
>
> -- debconf-show failed
>

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 2965 bytes --]

On 04/24/2014 03:12 PM, Rob Browning wrote:
> [If possible, please preserve the 745553-forwarded address in any replies.]
> 
> This bug was filed recently, and I suspect it might be something you'd
> like to discuss upstream.

thanks for forwarding this, Rob.

More notes below:

> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
 [...]
>> Consider Alice, who has OpenPGP certificates for "Bob
>> <bob@example.org>" and "Carol <carol@example.org>" in her keyring (in
>> that order).  She has certified them both, so there is one valid
>> primary key for bob@example.org and one valid primary key for
>> alice@example.org.
>>
>> Bob turns evil (or maybe his key is compromised) and he adds a new
>> User ID: "Bob <carol@example.org>" to his OpenPGP cert.  He publishes
>> the update to the keyservers.
>>
>> Alice, following best practices, updates her keyring from the
>> keyservers regularly.
>>
>> Alice's keyring now has two certs that have a "carol@example.org" user
>> ID in them.  One of them is valid, and the other one is not.
>>
>> Alice now composes a message to "Carol <carol@example.org>" and marks
>> it with:
>>
>>  <#secure method=pgpmime mode=signencrypt>
>>
>> As the message goes out, mml-mode just passes the e-mail address
>> carol@example.org to gpg to encrypt the message body, and gpg uses the
>> e-mail address to select a key.  Since Bob's key is first in the
>> keyring, it is the one that will be used.

Turns out the situation is slightly worse than i described above.  While
i still think that mml2015-always-trust should default to nil (and this
defends against some failure modes), there are other problems with key
selection that aren't fixed yet.

In particular, the problematic scenario described above is *not* fixed
by changing the setting.  Observing the behavior, it looks like mml-mode
does OpenPGP certificate selection by e-mail address in the following
way (sorry i haven't dug into the code yet):

 0) it asks GnuPG for a cert associated with the given e-mail address

 1) it checks the *overall* validity of the cert in order to decide if
the cert is the right one

 2) if the cert is valid, it encrypts to it.

The problem with this is how gpg defines the overall validity of the
cert: in particular, it defines the validity of a cert as the *highest*
validity of any UserID associated with the cert.  It should instead be
looking at the validity of the desired User ID specifically, not the
overall cert.

So in the scenario above, Bob's cert is still overall valid (because it
has a valid certification over the correct UserID+key from Alice), even
though the carol@example.org UserID is invalid.

I don't know mml-mode or elisp well enough to dig into the code and fix
this part of the problem quickly, but if someone has patches that i can
look at that would point to where it might be changed, i'd be happy to
try to review them.

	--dkg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1010 bytes --]

bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Lars Ingebrigtsen]

Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

> So in the scenario above, Bob's cert is still overall valid (because it
> has a valid certification over the correct UserID+key from Alice), even
> though the carol@example.org UserID is invalid.
>
> I don't know mml-mode or elisp well enough to dig into the code and fix
> this part of the problem quickly, but if someone has patches that i can
> look at that would point to where it might be changed, i'd be happy to
> try to review them.

I'm also mostly unfamiliar with the mml encryption code, but perhaps
Jens could take a peek at this?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#17338: bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Jens Lechtenboerger]

On 2017-01-25, at 18:19, Lars Ingebrigtsen wrote:

> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
>
>> So in the scenario above, Bob's cert is still overall valid (because it
>> has a valid certification over the correct UserID+key from Alice), even
>> though the carol@example.org UserID is invalid.
>>
>> I don't know mml-mode or elisp well enough to dig into the code and fix
>> this part of the problem quickly, but if someone has patches that i can
>> look at that would point to where it might be changed, i'd be happy to
>> try to review them.
>
> I'm also mostly unfamiliar with the mml encryption code, but perhaps
> Jens could take a peek at this?

mml2015-always-trust is replaced by mml-secure-openpgp-always-trust
nowadays.  I certainly wouldn’t object if the default value was
changed, but lots of long-term users might be surprised.

Also, nowadays, if multiple keys are available for a recipient, the
user is asked which key to use and whether to store that choice.

Then, EasyPG is responsible for calling GnuPG.  Maybe something
needs to be adjusted there as well.  What is the expected command
line behavior?

Best wishes
Jens

bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 2506 bytes --]

On Wed 2017-01-25 15:09:47 -0500, Jens Lechtenboerger wrote:
> On 2017-01-25, at 18:19, Lars Ingebrigtsen wrote:
>
>> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
>>
>>> So in the scenario above, Bob's cert is still overall valid (because it
>>> has a valid certification over the correct UserID+key from Alice), even
>>> though the carol@example.org UserID is invalid.
>>>
>>> I don't know mml-mode or elisp well enough to dig into the code and fix
>>> this part of the problem quickly, but if someone has patches that i can
>>> look at that would point to where it might be changed, i'd be happy to
>>> try to review them.
>>
>> I'm also mostly unfamiliar with the mml encryption code, but perhaps
>> Jens could take a peek at this?
>
> mml2015-always-trust is replaced by mml-secure-openpgp-always-trust
> nowadays.  I certainly wouldn’t object if the default value was
> changed, but lots of long-term users might be surprised.

It's also possible that lots of long-term users might be surprised to
find that refreshing one key in their keyring is likely to cause a
change in behavior for the use of other keys in their keyring.  this is
a silent surprise, which seems worse than a public surprise.

> Also, nowadays, if multiple keys are available for a recipient, the
> user is asked which key to use and whether to store that choice.

And how is that choice stored?  How and when can it be revisited by the
user?  What happens if that choice becomes invalid in the future
(e.g. the primary key, or the encryption-capable subkey is revoked,
expired, etc)?

> Then, EasyPG is responsible for calling GnuPG.  Maybe something
> needs to be adjusted there as well.  What is the expected command
> line behavior?

Modern versions of GnuPG automatically select the key which GnuPG knows
to have the best validity among all matches for the selector, thanks to
work put in by Justus Winter (cc'ed), so letting GnuPG make the decision
would relieve emacs of most of the hard work here, and would also mean
that any changes that the user makes to their GnuPG keyring would
automatically take effect in emacs without mml-mode needing to do
anything.

Modern versions of GnuPG also provide a "tofu" mechanism to store and
track that kind of decision in.  Neal Walfield (also cc'ed here) put in
a lot of that implementation, so he might have some suggestions for the
best way to handle it.

Thanks for looking into this, Lars and Jens!

     --dkg


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Jens Lechtenboerger]

On 2017-01-25, at 15:30, Daniel Kahn Gillmor wrote:

> On Wed 2017-01-25 15:09:47 -0500, Jens Lechtenboerger wrote:

>> mml2015-always-trust is replaced by mml-secure-openpgp-always-trust
>> nowadays.  I certainly wouldn’t object if the default value was
>> changed, but lots of long-term users might be surprised.
>
> It's also possible that lots of long-term users might be surprised to
> find that refreshing one key in their keyring is likely to cause a
> change in behavior for the use of other keys in their keyring.  this is
> a silent surprise, which seems worse than a public surprise.

Sorry, I don’t understand this.  What change in one key is causing
silent changes for other keys?

>> Also, nowadays, if multiple keys are available for a recipient, the
>> user is asked which key to use and whether to store that choice.
>
> And how is that choice stored?  How and when can it be revisited by the
> user?  What happens if that choice becomes invalid in the future
> (e.g. the primary key, or the encryption-capable subkey is revoked,
> expired, etc)?

That’s customized in mml-secure-key-preferences.  So, the usual
customize interface is available.  And there is some code to detect
and remove unusable customizations.

>> Then, EasyPG is responsible for calling GnuPG.  Maybe something
>> needs to be adjusted there as well.  What is the expected command
>> line behavior?
>
> Modern versions of GnuPG automatically select the key which GnuPG knows
> to have the best validity among all matches for the selector, thanks to
> work put in by Justus Winter (cc'ed), so letting GnuPG make the decision
> would relieve emacs of most of the hard work here, and would also mean
> that any changes that the user makes to their GnuPG keyring would
> automatically take effect in emacs without mml-mode needing to do
> anything.

The mml code is based on EasyPG by Daiki Ueno (cc’ed).  EasyPG makes
use of sub-keys and their IDs for encryption commands, instead of
relying on GnuPG’s selections.

> Modern versions of GnuPG also provide a "tofu" mechanism to store and
> track that kind of decision in.  Neal Walfield (also cc'ed here) put in
> a lot of that implementation, so he might have some suggestions for the
> best way to handle it.

If Emacs was relying on GnuPG’s decisions, nothing special would be
necessary for tofu, right?  (Users could activate that in their
gpg.conf.)

Best wishes
Jens

bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Daiki Ueno]

Jens Lechtenboerger <jens.lechtenboerger@fsfe.org> writes:

>> Modern versions of GnuPG automatically select the key which GnuPG knows
>> to have the best validity among all matches for the selector, thanks to
>> work put in by Justus Winter (cc'ed), so letting GnuPG make the decision
>> would relieve emacs of most of the hard work here, and would also mean
>> that any changes that the user makes to their GnuPG keyring would
>> automatically take effect in emacs without mml-mode needing to do
>> anything.
>
> The mml code is based on EasyPG by Daiki Ueno (cc’ed).  EasyPG makes
> use of sub-keys and their IDs for encryption commands, instead of
> relying on GnuPG’s selections.

It was suggested by Werner to do key selection in Emacs, like GPGME.  I
don't know whether GPGME changed the logic though.

>> Modern versions of GnuPG also provide a "tofu" mechanism to store and
>> track that kind of decision in.  Neal Walfield (also cc'ed here) put in
>> a lot of that implementation, so he might have some suggestions for the
>> best way to handle it.

I'm afraid I wouldn't do any work toward tofu at this level of quality;
in particular, until they reach the consensus whether tofu is only
activated when encryption is triggered by an email address.

Regards,
-- 
Daiki Ueno

bug#17338: bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Daniel Kahn Gillmor]

On Thu 2017-01-26 13:36:09 -0500, Jens Lechtenboerger wrote:
> On 2017-01-25, at 15:30, Daniel Kahn Gillmor wrote:
>> On Wed 2017-01-25 15:09:47 -0500, Jens Lechtenboerger wrote:
>>> mml2015-always-trust is replaced by mml-secure-openpgp-always-trust
>>> nowadays.  I certainly wouldn’t object if the default value was
>>> changed, but lots of long-term users might be surprised.
>>
>> It's also possible that lots of long-term users might be surprised to
>> find that refreshing one key in their keyring is likely to cause a
>> change in behavior for the use of other keys in their keyring.  this is
>> a silent surprise, which seems worse than a public surprise.
>
> Sorry, I don’t understand this.  What change in one key is causing
> silent changes for other keys?

Without the notification that multiple keys are available, Bob can add
Carol's User ID to his cert ; depending on where the certs are
positioned linearly in Alice's keyring, mail to Carol might be encrypted
to Bob's key, or to Alice's key.

I think this is mitigated at least in part by prompting the user when
there are multiple keys available, though.

> That’s customized in mml-secure-key-preferences.  So, the usual
> customize interface is available.  And there is some code to detect
> and remove unusable customizations.

When was this introduced?  i don't see it, but then i'm still using
emacs24.  Do i need to upgrade?

>> Modern versions of GnuPG also provide a "tofu" mechanism to store and
>> track that kind of decision in.  Neal Walfield (also cc'ed here) put in
>> a lot of that implementation, so he might have some suggestions for the
>> best way to handle it.
>
> If Emacs was relying on GnuPG’s decisions, nothing special would be
> necessary for tofu, right?  (Users could activate that in their
> gpg.conf.)

Neal can answer this better than i can.  I think the TOFU mode works
best when there's a bit of UI integration -- emacs would provide the way
for the user to answer a question prompted by gpg, and then gpg is
responsible for storing/tracking all the info.

            --dkg

bug#17338: bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

On Thu 2017-01-26 14:34:22 -0500, Daiki Ueno wrote:
> Jens Lechtenboerger <jens.lechtenboerger@fsfe.org> writes:
>> The mml code is based on EasyPG by Daiki Ueno (cc’ed).  EasyPG makes
>> use of sub-keys and their IDs for encryption commands, instead of
>> relying on GnuPG’s selections.
>
> It was suggested by Werner to do key selection in Emacs, like GPGME.  I
> don't know whether GPGME changed the logic though.

I don't know what this means -- i don't think that GPGME itself does key
selection.  Can you tell me more?

Presumably users who use emacs with gpg also use gpg with other tools
(possibly even other MUAs), or even gpg on its own.  Collecting key
preference data in multiple places while sharing the underlying key
store seems like a recipe for synchronization problems and confusing
behavior, particularly for folks who don't know how the tools fit
together.


>>> Modern versions of GnuPG also provide a "tofu" mechanism to store and
>>> track that kind of decision in.  Neal Walfield (also cc'ed here) put in
>>> a lot of that implementation, so he might have some suggestions for the
>>> best way to handle it.
>
> I'm afraid I wouldn't do any work toward tofu at this level of quality;
> in particular, until they reach the consensus whether tofu is only
> activated when encryption is triggered by an email address.

I don't think i understand this either.  Can you explain more about what
you need from the GnuPG TOFU code?

Thanks for this discussion, hopefully it'll lead somewhere fruitful.

       --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

On Wed 2017-01-25 15:09:47 -0500, Jens Lechtenboerger wrote:
> mml2015-always-trust is replaced by mml-secure-openpgp-always-trust
> nowadays.  I certainly wouldn’t object if the default value was
> changed, but lots of long-term users might be surprised.

hm, i just noticed that mml-secure-openpgp-always-trust isn't in emacs24
either.  is this also limited to emacs25?  Maybe this change of variable
is a good chance to do the transition to a better default.

         --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Daiki Ueno]

Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

> On Thu 2017-01-26 14:34:22 -0500, Daiki Ueno wrote:
>> Jens Lechtenboerger <jens.lechtenboerger@fsfe.org> writes:
>>> The mml code is based on EasyPG by Daiki Ueno (cc’ed).  EasyPG makes
>>> use of sub-keys and their IDs for encryption commands, instead of
>>> relying on GnuPG’s selections.
>>
>> It was suggested by Werner to do key selection in Emacs, like GPGME.  I
>> don't know whether GPGME changed the logic though.
>
> I don't know what this means -- i don't think that GPGME itself does key
> selection.  Can you tell me more?

My wording might be confusing; let me rephase: I don't think GPGME has a
means of using GnuPG's selections, which the applications can rely on.

EasyPG is modelled after GPGME, and Gnus is an application using it,
thus it is a responsiblity of Gnus to select usable keys by itself.

> Presumably users who use emacs with gpg also use gpg with other tools
> (possibly even other MUAs), or even gpg on its own. Collecting key
> preference data in multiple places while sharing the underlying key
> store seems like a recipe for synchronization problems and confusing
> behavior, particularly for folks who don't know how the tools fit
> together.

If there is the means to do that in GPGME now, yes, it would be nice for
EasyPG to provide a similar mechanism which can be used from Gnus.
Otherwise, IMO, neither EasyPG nor Gnus should try to do the selection
by calling gpg directly, even if it could be useful.

Regards,
-- 
Daiki Ueno

bug#17338: bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Daiki Ueno]

Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

> On Thu 2017-01-26 14:34:22 -0500, Daiki Ueno wrote:
>> Jens Lechtenboerger <jens.lechtenboerger@fsfe.org> writes:
>>> The mml code is based on EasyPG by Daiki Ueno (cc’ed).  EasyPG makes
>>> use of sub-keys and their IDs for encryption commands, instead of
>>> relying on GnuPG’s selections.
>>
>> It was suggested by Werner to do key selection in Emacs, like GPGME.  I
>> don't know whether GPGME changed the logic though.
>
> I don't know what this means -- i don't think that GPGME itself does key
> selection.  Can you tell me more?

My wording might be confusing; let me rephase: I don't think GPGME has a
means of using GnuPG's selections, which the applications can rely on.

EasyPG is modelled after GPGME, and Gnus is an application using it,
thus it is a responsiblity of Gnus to select usable keys by itself.

> Presumably users who use emacs with gpg also use gpg with other tools
> (possibly even other MUAs), or even gpg on its own. Collecting key
> preference data in multiple places while sharing the underlying key
> store seems like a recipe for synchronization problems and confusing
> behavior, particularly for folks who don't know how the tools fit
> together.

If there is the means to do that in GPGME now, yes, it would be nice for
EasyPG to provide a similar mechanism which can be used from Gnus.
Otherwise, IMO, neither EasyPG nor Gnus should try to do the selection
by calling gpg directly, even if it could be useful.

Regards,
-- 
Daiki Ueno

bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Jens Lechtenboerger]

On 2017-01-26, at 18:13, Daniel Kahn Gillmor wrote:

> On Thu 2017-01-26 13:36:09 -0500, Jens Lechtenboerger wrote:

>> That’s customized in mml-secure-key-preferences.  So, the usual
>> customize interface is available.  And there is some code to detect
>> and remove unusable customizations.
>
> When was this introduced?  i don't see it, but then i'm still using
> emacs24.  Do i need to upgrade?

I introduced that about a year ago, when Gnus was still developed in
its own repository.  I don’t know anything about Gnus releases since
then.

The doc string reports those changes as of version 25.1 of Emacs.

Best wishes
Jens

bug#17338: bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Lars Ingebrigtsen]

Jens Lechtenboerger <jens.lechtenboerger@fsfe.org> writes:

> mml2015-always-trust is replaced by mml-secure-openpgp-always-trust
> nowadays.  I certainly wouldn’t object if the default value was
> changed, but lots of long-term users might be surprised.
>
> Also, nowadays, if multiple keys are available for a recipient, the
> user is asked which key to use and whether to store that choice.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Skimming this bug report, it seems like this is working as designed, so
I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no