Mailing List Archive

By the Way, this goes for the vast Majority of People that drives, heats aso. by Oil and Gas as well.

Am 2019-10-13 um 08:21 schrieb Patrick Brunschwig:

BruderB wrote on 12.10.2019 10:43:

Hej all, Am 12.10.19 um 08:23 schrieb Robert J. Hansen:

they're going to insist on running their own keyring internal to Thunderbird which isn't shared with anything else. (I imagine *importing* from a GnuPG keyring will be supported, but *sharing* a keyring is right out.)

_They_ can insist on whatever they want. If they close their shop towards external built keys (for example with xca), they hopefully won't find much acceptance.....

The vast majority of users of Enigmail (somewhere around 98%) don't use external built keys. The vast majority of users also don't use GnuPG for anything else than email. These users don't care where their key is stored, nor which software under the hood is used for the crypto. All they care is that encryption works smoothly. I'm sorry, but everything written here is pure speculation. We are still in the phase of considering our options. Depending on the chosen approach, we may just as well end up with something completely different than what you'd imagine. The most important aspects from our side are the following: The chosen solution must run smoothly for the ~20M users of Thunderbird without causing a large amount of support/setup issues. We want to have something that satisfies as many users of Enigmail as possible. We certainly don't want to have people run away from Thunderbird because of OpenPGP. -Patrick _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users"]http://lists.gnupg.org/mailman/listinfo/gnupg-users

-- <pre> -========================== Jan-Peter Rühmann & Kuma =========================- Gubkower Str.7 [ Tel.: +49 38205 65484 ] jan-Peter@ruehmann.name 18195 Cammin / Prangendorf [ FAX: +49 38205 65212 ] https://www.ruehmann.name"]https://www.ruehmann.name WhatsApp: 491621316054 [ Tel.: +49 38205 65215 ] Twitter: @JPRuehmann [ Mobil: +49 162 1316054 ] IT-Servicetechniker -=============================================================================- Die Verwendung der Daten zu Werbezwecken ist verboten. </pre>

On Sat, 12 Oct 2019 12:43, Chris Narkiewicz said:

> Do you know why they resited OpenPGP adoption it so much?

iirc, they said that they want to support only one protocol and settled
for S/MIME. This still did not explain why they rejected our proposal
to clean up their S/MIME code and implement missing stuff so that TB
could be used for tasks of the German administrative and to be
compatible with a wider range of S/MIME implementations. The plan was
to do that all within TB and without external dependencies.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Werner Koch via Gnupg-users wrote on 13.10.2019 11:56:
> On Sat, 12 Oct 2019 12:43, Chris Narkiewicz said:
>
>> Do you know why they resited OpenPGP adoption it so much?
>
> iirc, they said that they want to support only one protocol and settled
> for S/MIME. This still did not explain why they rejected our proposal
> to clean up their S/MIME code and implement missing stuff so that TB
> could be used for tasks of the German administrative and to be
> compatible with a wider range of S/MIME implementations. The plan was
> to do that all within TB and without external dependencies.

I think there are two reasons why TB changed their minds:
1. there are different people working on Thunderbird than years ago.
2. in the past, TB was a direct part of Mozilla. Now, Thunderbird is an
independent organization under the umbrella of the Mozilla Foundation,
with an independent council and their own independent financial income
stream.

These two factors lead to a completely different mindset towards what is
good for TB.

-Patrick

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 08.10.2019 09:08, Patrick Brunschwig wrote:
> The Thunderbird developers have announced that they will implement
> OpenPGP support in Thunderbird 78 [1]. Support for Thunderbird in
> Enigmail will therefore be discontinued.
>
> [Snip]
>
> I will continue to support and maintain Enigmail for Thunderbird 68
> until 6 months after Thunderbird 78 will have been released (i.e. a few
> months beyond Thunderbird 68 EOL). Enigmail will not run anymore on
> Thunderbird 72 beta and newer.

IMHO, integrating PGP into TB in general is a good decision. However, I
have two concerns (being a naive user, and being far away from
understanding the technical aspects).

1) The schedule

We have all been educated to update our applications (notably, "internet
applications" like browser and email clients) as soon as updates are
available; at least, this is true for security updates.

Despite release plans, I think nobody knows for sure how much time
actually will pass between TB 72's predecessor and TB 78, and how many
security updates will be released between these versions.

During that time, I either can't use Enigmail (if I decide to install
the security updates), or I have to ignore the security updates
(possibly putting me to risk).

Did I understand this correctly?

I am not on a level that I would use GnuPG on the command line to
encrypt or authenticate my messages (encryption is fascinating, and if I
had the time, it would be a pleasure to dive deeply into this subject,
but for the time being, I just need it working), so I am dependent on
the TB / Enigmail duo (at least until TB 78).

2) The features

When integrating PGP into TB, IMHO great attention must be paid that
none of the important features of Enigmail / GnuPG get lost, not even in
the first version. The statement that the first implementation probably
will be "less feature-rich" than Enigmail (let alone GnuPG) really
frightens me and lets me expect all sorts of problems.

For example, even I (as a non-advanced user) recently had an issue where
I could not use PGP keys which were generated by Enigmail, because the
keys' IDs were formally wrong so that key servers didn't accept the
keys. The easiest possible solution was to re-generate these keys using
GnuPG on the command line (despite my statement above ...) and import
them into Enigmail.

This simple case shows that we actually need the full functionality of a
mature software package like GnuPG from the beginning on (note that my
problem was ridiculously simple, but even then I couldn't easily solve
it using Enigmail alone).

My feeling is that TB (and probably email encryption / authentication
per se) will lose a lot of users (including me) if the first
implementation lacks essential features, makes the encryption setup fail
due to common problems (like mine), or makes encryption unusable or
difficult in any other way.

By the way, being able to encrypt the subject of an encrypted message
also is one of the essential features (thanks, Patrick, and thanks,
Werner, that you finally have made this possible a while ago!) ...

Just my 2 cents ...

Regards,

Binarus

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Sun, 13 Oct 2019 18:27, Binarus said:

> keys' IDs were formally wrong so that key servers didn't accept the
> keys. The easiest possible solution was to re-generate these keys using

For the records: Not /keyservers/ but one specific keyserver which runs
on a not yet matured enough code base and is thus expected to have bugs.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

On 13.10.2019 18:51, Werner Koch wrote:
> On Sun, 13 Oct 2019 18:27, Binarus said:
>
>> keys' IDs were formally wrong so that key servers didn't accept the
>> keys. The easiest possible solution was to re-generate these keys using
>
> For the records: Not /keyservers/ but one specific keyserver which runs
> on a not yet matured enough code base and is thus expected to have bugs.
>

Thank you very much for your remark.

Actually, I have meant this to be just an example for the problems to
expect if too many features are missing.

Secondly, I suspect that there are more keyservers out there (running
other software) which also would reject those keys (I didn't try,
though, so this is speculation).

Thirdly, this is the keyserver which is preset in Enigmail (I didn't
change the default). For naive users like me, it is not possible to
check a keyserver's software version and to analyze how mature / stable
it is. I even wouldn't come to that idea, because this is the default
keyserver in a well-known software package :-) If I wouldn't have been
able to generate correct keys / IDs using GnuPG directly, I eventually
would have given up on encryption.

Regards,

Binarus

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 10/13/19 2:21 AM, Patrick Brunschwig wrote:
> The vast majority of users of Enigmail (somewhere around 98%) don't use
> external built keys.

How do you know this?

> The vast majority of users also don't use GnuPG for
> anything else than email. These users don't care where their key is
> stored, nor which software under the hood is used for the crypto. All
> they care is that encryption works smoothly.

And this?

> The most important aspects from our side are the following: The chosen
> solution must run smoothly for the ~20M users of Thunderbird without
> causing a large amount of support/setup issues.

Presumably those ~20,000,000 will have to opt-in to use Thunderbird
encryption. Most won't for the same reason they don't install and use
Enigmail now. They don't particularly care about privacy, and the few
who do care correspond with people who don't.

> We want to have
> something that satisfies as many users of Enigmail as possible. We
> certainly don't want to have people run away from Thunderbird because of
> OpenPGP.

If responses to my posts in the "We have GOT TO make things simpler"
thread are any indication, you'll be looking at quite a few back sides.
Is there any reason to think that folks who object to easy-to-use
proprietary encrypted email solutions from ProtonMail and Tutanota will
embrace a proprietary encrypted email solution from Thunderbird?

Jeff Allen

Binarus wrote on 13.10.2019 18:27:
[...]
> 1) The schedule
>
> We have all been educated to update our applications (notably, "internet
> applications" like browser and email clients) as soon as updates are
> available; at least, this is true for security updates.
>
> Despite release plans, I think nobody knows for sure how much time
> actually will pass between TB 72's predecessor and TB 78, and how many
> security updates will be released between these versions.
>
> During that time, I either can't use Enigmail (if I decide to install
> the security updates), or I have to ignore the security updates
> (possibly putting me to risk).
>
> Did I understand this correctly?

The current stable version of Thunderbird is 68 (and 60 for a few more
weeks); the next stable version will be 78. Users of Enigmail staying on
the stable version of Thunderbird will receive all security updates
until TB 78 will be available. Thunderbird 69 ... 77 are only released
as beta versions that are not intended for end users.

-Patrick

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 13.10.2019 22:27, Jeff Allen via Gnupg-users wrote:
> On 10/13/19 2:21 AM, Patrick Brunschwig wrote:
>> The vast majority of users of Enigmail (somewhere around 98%) don't use
>> external built keys.
>
> How do you know this?
>

I don't know either, but perhaps it is in the debug logs the Enigmail
team analyzes?

>> The vast majority of users also don't use GnuPG for
>> anything else than email. These users don't care where their key is
>> stored, nor which software under the hood is used for the crypto. All
>> they care is that encryption works smoothly.
>
> And this?
>

I am also not sure about this. As far as it concerns Windows, the first
part of the statement may be true. There is plenty of software to
encrypt single files or directories for Windows, including the software
which is part of the O/S. People probably tend to go the easiest way,
even if another solution would be safer and technically superior. I
don't know the situation under Linux well enough to comment.

I disagree with the second part of the statement, though. Most of the
people who think about privacy and email encryption / authentication at
all are educated, non-average users who want to be sure that there are
no backdoors in their software and that they use it as safely as
possible (meaning that they care about software, algorithms and
ciphers), and who want to backup their keys (meaning that they care
where the keys are stored). And yes, I want to decide on my own if my
key is ED25519, RSA1024 or RSA4096 :-)

>> The most important aspects from our side are the following: The chosen
>> solution must run smoothly for the ~20M users of Thunderbird without
>> causing a large amount of support/setup issues.
>
> Presumably those ~20,000,000 will have to opt-in to use Thunderbird
> encryption. Most won't for the same reason they don't install and use
> Enigmail now. They don't particularly care about privacy, and the few
> who do care correspond with people who don't.
>

I am not sure where this will lead to. It sounds as if you were
suggesting to give up on privacy, encryption and authentication for that
reason.

While I agree with you that this problem exists and is quite difficult
to solve (eventually it needs another decade), I am absolutely sure that
bad and difficult software will make it worse, but good and usable
software will help in solving it. The fact that the problem exists does
not mean that nobody should try to solve it by providing easier-to-use,
fully integrated software with reasonable default settings.

>> We want to have
>> something that satisfies as many users of Enigmail as possible. We
>> certainly don't want to have people run away from Thunderbird because of
>> OpenPGP.
>
> [Snip]
>
> Is there any reason to think that folks who object to easy-to-use
> proprietary encrypted email solutions from ProtonMail and Tutanota will
> embrace a proprietary encrypted email solution from Thunderbird?
>

There are many reasons to think so (the following applies to ProtonMail
as well as Tutanota):

1) To actually use those services in a reasonable manner, you have to
opt-in for a paid contract. For most of us, this is a matter of
principle. Why should we pay for a thing that used to be free all the
time? (Note: I don't want to judge that attitude - I am just stating how
it is).

2) None of that services supports IMAP or POP3. I would be totally crazy
if I would make myself totally dependent on companies or services which
won't let me download my messages and integrate them into my email client.

What happens if those companies suddenly stop their service and you
haven't downloaded your messages yet (which anyway seems to be
impossible)? Or if you decide that you want to use another service? How
long will you be able to access your messages after you have stopped
paying your old service? Will they delete your messages until the quota
for free usage is reached again?

I insist on having all important data, including email messages,
in-house and under my complete control, and I strongly advise each of my
customers to do the same. So far, all of them are following that advice.
Therefore, such services never will have any chance to do business with
my customers.

3) I have several email addresses. I am definitely not ready to use a
different website or different software for each of them. That is, there
is absolutely no chance that I ever will use a service which does not
provide POP3 or IMAP (or, for the protocol, their successors).

I want *one* MUA (like Thunderbird) to be able to manage *all* of my
email messages in *one* place (For example, ever needed to search for a
message for which you can't remember the account it was received on? -
The global search in TB is very handy here. Further reasons: junk
filtering, action filters (automatically moving certain messages in
subfolders) and so on, all managed at one place, public folders, shared
folders and so on).

4) I doubt that these services can be legally used by businesses in
Germany. We are having some weird rules here, one of them saying that we
have to keep *each* (electronic) message we are receiving and sending in
a separate archive where users don't have access to. That is, users of
course may do anything they want in their normal email account, but all
messages which are ever sent or received must first be copied somewhere
where they cannot be manipulated or deleted.

I can't imagine how this could be achieved when using those services.

These are only a few of the many reasons against using a purely
cloud-based email system.

Regards,

Binarus

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 14.10.2019 09:17, Patrick Brunschwig wrote:
> Binarus wrote on 13.10.2019 18:27:
> [...]
>> 1) The schedule
>>
>> We have all been educated to update our applications (notably, "internet
>> applications" like browser and email clients) as soon as updates are
>> available; at least, this is true for security updates.
>>
>> Despite release plans, I think nobody knows for sure how much time
>> actually will pass between TB 72's predecessor and TB 78, and how many
>> security updates will be released between these versions.
>>
>> During that time, I either can't use Enigmail (if I decide to install
>> the security updates), or I have to ignore the security updates
>> (possibly putting me to risk).
>>
>> Did I understand this correctly?
>
> The current stable version of Thunderbird is 68 (and 60 for a few more
> weeks); the next stable version will be 78. Users of Enigmail staying on
> the stable version of Thunderbird will receive all security updates
> until TB 78 will be available. Thunderbird 69 ... 77 are only released
> as beta versions that are not intended for end users.
>

I see. Thank you very much for the clarification. This relieves a lot of
tension.

Regards,

Binarus

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 10/14/19 3:40 AM, Binarus wrote:
>
> On 13.10.2019 22:27, Jeff Allen via Gnupg-users wrote:
>> On 10/13/19 2:21 AM, Patrick Brunschwig wrote:
>>> The vast majority of users of Enigmail (somewhere around 98%) don't use
>>> external built keys.
>>
>> How do you know this?
>>
>
> I don't know either, but perhaps it is in the debug logs the Enigmail
> team analyzes?

I have used Enigmail since its inception and have never knowingly
submitted a log or answered a survey and have always assumed Enigmail
does not phone home.

>>> The vast majority of users also don't use GnuPG for
>>> anything else than email. These users don't care where their key is
>>> stored, nor which software under the hood is used for the crypto. All
>>> they care is that encryption works smoothly.
>>
>> And this?
>>
>
> I am also not sure about this. As far as it concerns Windows, the first
> part of the statement may be true.

All the statements might be true. My question was "How do you know?"

<snip>

> I disagree with the second part of the statement, though. Most of the
> people who think about privacy and email encryption / authentication at
> all are educated, non-average users who want to be sure that there are
> no backdoors in their software and that they use it as safely as
> possible (meaning that they care about software, algorithms and
> ciphers), and who want to backup their keys (meaning that they care
> where the keys are stored). And yes, I want to decide on my own if my
> key is ED25519, RSA1024 or RSA4096 :-)

I agree and think Patrick underestimates the number of GnuPG/Enigmail
users who care a lot about the details. My argument in the other thread
was that folks who value privacy and encryption but can't be burdened by
the details have reasonably secure easy-to-use options available.
Enigmail is, of course, one of them.

>>> The most important aspects from our side are the following: The chosen
>>> solution must run smoothly for the ~20M users of Thunderbird without
>>> causing a large amount of support/setup issues.
>>
>> Presumably those ~20,000,000 will have to opt-in to use Thunderbird
>> encryption. Most won't for the same reason they don't install and use
>> Enigmail now. They don't particularly care about privacy, and the few
>> who do care correspond with people who don't.
>>
>
> I am not sure where this will lead to. It sounds as if you were
> suggesting to give up on privacy, encryption and authentication for that
> reason.

Not at all. My point was that I doubt OpenPGP's inclusion in
Thunderbird will have a major impact on the number of people encrypting
their email.

> While I agree with you that this problem exists and is quite difficult
> to solve (eventually it needs another decade), I am absolutely sure that
> bad and difficult software will make it worse, but good and usable
> software will help in solving it. The fact that the problem exists does
> not mean that nobody should try to solve it by providing easier-to-use,
> fully integrated software with reasonable default settings.

Here we disagree. I believe that existing software is not that
difficult to use. The problem, if there is one, is that most people
simply aren't interested. Twenty years ago I thought that everyone
would soon be using end-to-end encrypted email. Twenty years from now
they still won't be.

>>> We want to have
>>> something that satisfies as many users of Enigmail as possible. We
>>> certainly don't want to have people run away from Thunderbird because of
>>> OpenPGP.
>>
>> [Snip]
>>
>> Is there any reason to think that folks who object to easy-to-use
>> proprietary encrypted email solutions from ProtonMail and Tutanota will
>> embrace a proprietary encrypted email solution from Thunderbird?
>>
>
> There are many reasons to think so (the following applies to ProtonMail
> as well as Tutanota):
>
> 1) To actually use those services in a reasonable manner, you have to
> opt-in for a paid contract. For most of us, this is a matter of
> principle. Why should we pay for a thing that used to be free all the
> time? (Note: I don't want to judge that attitude - I am just stating how
> it is).

<snip>

But "free" email has never been free from the likes of Gmail, Yahoo,
GMX, etc. While you don't pay a yearly fee, you trade your privacy for
a few bucks. You open yourself to tracking and targeted advertising.
Your email is anything but private. A couple years back both Google and
Yahoo claimed to be working on E2EE. I wonder why it never happened?

The free versions of ProtonMail, Tutanota and Mailfence at least
preserve your privacy. They aren't monetized through advertising and
tracking. Instead they sell premium services to people who want more
capacity or features. Many people I know do email exclusively on their
smart phones. They don't use an MUA and don't care about POP3, IMAP or
SMTP. Their view of using email services in a reasonable manner doesn't
comport with yours or mine.

<snip>

I hope I am wrong and Thunderbird's OpenPGP implementation is a complete
success encouraging many more people to encrypt their email. I would,
however, personally prefer that Thunderbird directly implement GnuPG
integration instead of going it alone. That would satisfy both casual
and power users as Enigmail does now.

Will Thunderbird OpenPGP support smart cards like my Yubikey? How about
a feature like GnuPG's group line or Enigmail's per-recipient rules?
In-line PGP as well as PGP/MIME? Encrypted subject and the ability to
turn it on or off? As far as I know, they are all features of GnuPG or
Enigmail and not required by the OpenPGP specification.

Patrick and company deserve our thanks for many years splendid service
to the OpenPGP community. So does Werner and his team who created and
maintain a tool that has satisfied a wide range of users for decades. I
doubt that yet another proprietary OpenPGP system is what the world needs.

Jeff Allen

Werner Koch via Gnupg-users writes:

> Still, TB is still subject to those attacks because their primary
> encryption protocol is S/MIME and the last time I checked S/MIME (well,
> CMS for the nitpickers) does not supoport any kind of authenticated
> encryption. In contarst OpenPGP provides this nearly for 2 decades.

What do you mean? S/MIME authenticates the user's identity via the CA.


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Mon, 14 Oct 2019 10:54, Phillip Susi said:

>> encryption protocol is S/MIME and the last time I checked S/MIME (well,
>> CMS for the nitpickers) does not supoport any kind of authenticated
>> encryption. In contarst OpenPGP provides this nearly for 2 decades.
>
> What do you mean? S/MIME authenticates the user's identity via the CA.

authenticated encryption is different from signed and encrypted mails.
There are relative easy attacks on the encryption layer if standard
encryption modes like CBC (as in S/MIME) are used. Whether this really
affects users is a different question but they can be used to leverage
implementation flaws in MUAs to full plaintext leaks. This is known for
20 years and made it last year again to the media under the term EFAIL.

Granted, encrypted+signed mails can to a large extend also mitigate the
threat. But there are still reasons why signatures can't be used or
need to be verified only at a latter time in the workflow.

OpenPGP had a mitigation against this since 2000 and was widely deployed
by 2003. However S/MIME never implemented this despite of 10 years old
RFCs describing methods for such a mitigation, called authenticated
encryption (AE or AEAD).


Salam-Shalom,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Hello to all,

well it's a good thing, that openPGP shall be included to TB directly.

But ... as the Mozilla wiki [1] states in the FAQ-Section the following:


Q: Will OpenPGP cards be supported for private key storage ?

A: Probably not, because we don't use the GnuPG software that's usually
required to access OpenPGP smartcards.

This will not be usefull for me or my company, as we only use PGP Keys
stored on smartcards.
So I guess we will have to take TB down and find other solutions.

m2c
Juergen


[1] https://wiki.mozilla.org/Thunderbird:OpenPGP:2020

--
Juergen M. Bruckner
juergen@bruckner.tk

On 14.10.2019 18:54, Juergen Bruckner via Gnupg-users wrote:
> Hello to all,
>
> well it's a good thing, that openPGP shall be included to TB directly.
>
> But ... as the Mozilla wiki [1] states in the FAQ-Section the following:
>
>
> Q: Will OpenPGP cards be supported for private key storage ?
>
> A: Probably not, because we don't use the GnuPG software that's usually
> required to access OpenPGP smartcards.

I agree OpenPGP smartcard/token support is a must have, and brought this
up during this during this weekend's OpenPGP summit; please see the
[notes] section "Workshop: Thunderbird & OpenPGP" for some of the
discussion, specifically
"""
Although RNP doesn't support smartcards currently, a potential solution
was suggested by Kristian and Andre: talking to SCDaemon (scd) with IPC.
Details need to be discussed, but it would be an optional solution, that
only works if the user has installed software (scd etc.) in addition to
Thunderbird. How would this work? GnuPG as an optional dependency?
Outsourcing smartcard handling to scdaemon (scd), which is available
cross-platform through Unix socket or TCP/IP (windows) with usual user
system protection? Or... extend the RNP library to talk to scd? Needs
discussion and contributors, but that should wait until we're certain
what library TB will use.
"""

References:
[notes]
https://wiki.gnupg.org/OpenPGPEmailSummit201910Notes

--
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Corruptissima re publica plurimæ leges
The greater the degeneration of the republic, the more of its laws

On Mon, 14 Oct 2019 20:43, Kristian Fiskerstrand said:

> was suggested by Kristian and Andre: talking to SCDaemon (scd) with IPC.
> Details need to be discussed, but it would be an optional solution, that

Given that TB already has smartcard support it would be easy if the new
code just makes use of that code. Of course the code then needs to
touch the NSS part of Mozilla and can't just go with RNP. That would be
a more integrated solution than any other hack.

Right, separate software will be required but that is the usual case
with smartcards. For example Scute can be used to provide card services
via GnuPG (and also allow for on-disk GnuPG. Note that GnuPG 2.3 will
be much more flexible in regard to smartcard use and how it can interact
with TB via Scute.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

> I have used Enigmail since its inception and have never knowingly
> submitted a log or answered a survey and have always assumed Enigmail
> does not phone home.

It does not.

> Here we disagree. I believe that existing software is not that
> difficult to use. The problem, if there is one, is that most people
> simply aren't interested.

There's excellent academic research into why. I heartily recommend
reading this paper: "Secrecy, Flagging, and Paranoia: Adoption Criteria
in Encrypted Email". Shirley Gaw, Ed Felten, and Patricia
Fernandez-Kelly, out of Princeton University.

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.136.5612&rep=rep1&type=pdf

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 14.10.2019 22:45, Werner Koch wrote:
> On Mon, 14 Oct 2019 20:43, Kristian Fiskerstrand said:
>
>> was suggested by Kristian and Andre: talking to SCDaemon (scd) with IPC.
>> Details need to be discussed, but it would be an optional solution, that
>
> Given that TB already has smartcard support it would be easy if the new
> code just makes use of that code. Of course the code then needs to
> touch the NSS part of Mozilla and can't just go with RNP. That would be
> a more integrated solution than any other hack.
>
> Right, separate software will be required but that is the usual case
> with smartcards. For example Scute can be used to provide card services
> via GnuPG (and also allow for on-disk GnuPG. Note that GnuPG 2.3 will
> be much more flexible in regard to smartcard use and how it can interact
> with TB via Scute.

Scute might very well be a good alternative to reach out to, but I'm not
too optimistic regarding the likelihood of getting anything related to
OpenPGP directly into NSS, hence expecting anything that requires
development needs to be done through other vectors.


--
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Corruptissima re publica plurimæ leges
The greater the degeneration of the republic, the more of its laws

Werner Koch writes:

> authenticated encryption is different from signed and encrypted mails.
> There are relative easy attacks on the encryption layer if standard
> encryption modes like CBC (as in S/MIME) are used. Whether this really
> affects users is a different question but they can be used to leverage
> implementation flaws in MUAs to full plaintext leaks. This is known for
> 20 years and made it last year again to the media under the term EFAIL.

I'm confused. I thought the whole efail thing was about crafting a
plain text message that says "Good signature verified" and fools the
user even though it was never run through pgp or had its signature
verified with s/mime.

> Granted, encrypted+signed mails can to a large extend also mitigate the
> threat. But there are still reasons why signatures can't be used or
> need to be verified only at a latter time in the workflow.
>
> OpenPGP had a mitigation against this since 2000 and was widely deployed
> by 2003. However S/MIME never implemented this despite of 10 years old
> RFCs describing methods for such a mitigation, called authenticated
> encryption (AE or AEAD).

AFAICS, that is for encryption+sign. If you just want to sign, it
sounds like you are saying that is broken. I don't see how. You can't
modify the message and keep the hash unchanged, and you can't encrypt a
new hash because you don't have the sender's private key.


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> I'm confused. I thought the whole efail thing was about crafting a
> plain text message that says "Good signature verified" and fools the
> user even though it was never run through pgp or had its signature
> verified with s/mime.

I'd suggest reading the Efail paper. The vast majority of the news
coverage was shoddy. Efail included two *completely separate* attacks
in their paper, which the news media overwhelmingly conflated into a
single attack.

I'll call them Efail-1 and Efail-2 here.

Efail-1 was what Werner is talking about here. It was a pretty bad blow
to S/MIME, but far less so to OpenPGP, since OpenPGP has had
countermeasures in place for almost twenty years. Efail-1's impact on
OpenPGP was, is, minimal.

Efail-2 wasn't an attack on OpenPGP at all, but instead showed how
poorly email clients and/or email plugins communicated with GnuPG. It
was possible for GnuPG to give a correct warning that someone was
playing games with the message, and for the email client to disregard
this warning and present it to the user as authentic.

Efail-1 had minimal applicability to GnuPG; Efail-2 had none whatsoever
(except, arguably, some of the messages GnuPG gave were ambiguous: I
think they were, but Werner disagrees).

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> Efail-1 was what Werner is talking about here. It was a pretty bad
> blow to S/MIME, but far less so to OpenPGP, since OpenPGP has had
> countermeasures in place for almost twenty years. Efail-1's impact
> on OpenPGP was, is, minimal.
I actually spend a lot of time investigating the impact of EFAIL on
S/MIME and it's my opinion that the real impact has been overblown. In
all my experiments, and I can tell you I have done a lot of them, I have
not been able to force a mail client to actually forward the decrypted
content to a remote system.

The CBC attack is serious because modifying encrypted content is not
something you expect from a security point of view. But the real life
impact is not as big as they wanted us to believe (IMHO). I have asked
the EFAIL authors for examples on real life attacks (of the CBC problem
related to S/MIME) but I never got a real answer whether they were able
to use the attack in real life situation.

I think the problem with the paper was that they discusses two separate
issues. The issue with Efail-2 was serious but that was more an mail
client issue.

Kind regards,

Martijn

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 14.10.2019 16:15, Jeff Allen via Gnupg-users wrote:
>> I don't know either, but perhaps it is in the debug logs the Enigmail
>> team analyzes?
>
> I have used Enigmail since its inception and have never knowingly
> submitted a log or answered a survey and have always assumed Enigmail
> does not phone home.

I am sure that it doesn't phone home. However, to give an example, I had
a problem some years ago where Enigmail didn't work correctly any more
when a certain other extension was installed, or vice versa. I published
that problem somewhere (can't remember exactly) and got the advice to
turn on Enigmail debugging and send the debug log to a certain email
address or to publish it (again, can't remember). Of course, I followed
that advice (after having examined the log file and having convinced
myself that there was no critical data in it, as expected).

I suppose that the Enigmail team gets quite a lot of such debug logs.
But I still can't tell (and currently don't have the time to
investigate) if those logs can tell which keys had been generated by
Enigmail and which had been generated externally, so the whole thing was
a guess anyway.

>>>> The vast majority of users also don't use GnuPG for
>>>> anything else than email. These users don't care where their key is
>>>> stored, nor which software under the hood is used for the crypto. All
>>>> they care is that encryption works smoothly.
>>>
>>> And this?
>>>
>>
>> I am also not sure about this. As far as it concerns Windows, the first
>> part of the statement may be true.
>
> All the statements might be true. My question was "How do you know?"

Good point. I see.

>> I am not sure where this will lead to. It sounds as if you were
>> suggesting to give up on privacy, encryption and authentication for that
>> reason.
>
> Not at all. My point was that I doubt OpenPGP's inclusion in
> Thunderbird will have a major impact on the number of people encrypting
> their email

I think that even a minor impact would be desirable. The problem is: If
it is done wrong (essential features missing, e.g. subject encryption,
no exchange of keys with external tools, no hardware token support
etc.), it could prevent a large part of today's encryption users from
using encryption in the future, i.e. it even could reduce encryption
prevalence.

Personally, I am not sure what I'd do if the integration of PGP in TB
would be broken (i.e. no subject encryption, no control over key
generation and so on). Theoretically, I could move to another MUA which
provides a reasonable workflow for PGP, but due to pressure of time and
due to flaws or missing features in other MUAs I eventually would have
to stick with TB, even if I couldn't reasonably use PGP any more.

>> While I agree with you that this problem exists and is quite difficult
>> to solve (eventually it needs another decade), I am absolutely sure that
>> bad and difficult software will make it worse, but good and usable
>> software will help in solving it. The fact that the problem exists does
>> not mean that nobody should try to solve it by providing easier-to-use,
>> fully integrated software with reasonable default settings.
>
> Here we disagree. I believe that existing software is not that
> difficult to use. The problem, if there is one, is that most people
> simply aren't interested. Twenty years ago I thought that everyone
> would soon be using end-to-end encrypted email. Twenty years from now
> they still won't be.

Here the integration could really help. For example, keys could be
automatically generated whenever a new email account is created in TB.
Then, when sending the first message using that account, a dialog could
popup asking the user:

"We already have completely setup your PGP keys. Do you want to
authenticate this and further messages, and do you want to attach your
public key to each message so that the correspondents can encrypt their
replies to you, and do you want to upload your public key to server
x.y.z so that everybody can send you encrypted messages and can verify
your signature?"

I bet that 80% of users would answer this dialog by clicking "Yes", and
I think this would really help.

But once again, if too many features are missing in the integration,
this will throw back email encryption prevalence by one or two decades
because TB / Enigmail presumably is the most widespread software for
email encryption, and I am not sure how many users could move to another
MUA if PGP is broken / not fully usable in TB.

>> There are many reasons to think so (the following applies to ProtonMail
>> as well as Tutanota):
>>
>> 1) To actually use those services in a reasonable manner, you have to
>> opt-in for a paid contract. For most of us, this is a matter of
>> principle. Why should we pay for a thing that used to be free all the
>> time? (Note: I don't want to judge that attitude - I am just stating how
>> it is).
>
> <snip>
>
> But "free" email has never been free from the likes of Gmail, Yahoo,
> GMX, etc. While you don't pay a yearly fee, you trade your privacy for
> a few bucks. You open yourself to tracking and targeted advertising.
> Your email is anything but private. A couple years back both Google and
> Yahoo claimed to be working on E2EE. I wonder why it never happened?
>
> The free versions of ProtonMail, Tutanota and Mailfence at least
> preserve your privacy. They aren't monetized through advertising and
> tracking. Instead they sell premium services to people who want more
> capacity or features. Many people I know do email exclusively on their
> smart phones. They don't use an MUA and don't care about POP3, IMAP or
> SMTP. Their view of using email services in a reasonable manner doesn't
> comport with yours or mine.

Correct, but (as I wrote) I didn't want to judge the attitude; I just
wanted to show how it works. Many users reflexively close web pages
immediately as soon as they recognize a $ sign (except online shops and
TV / movie / music sites, of course).

> I hope I am wrong and Thunderbird's OpenPGP implementation is a complete
> success encouraging many more people to encrypt their email. I would,
> however, personally prefer that Thunderbird directly implement GnuPG
> integration instead of going it alone. That would satisfy both casual
> and power users as Enigmail does now.
>
> Will Thunderbird OpenPGP support smart cards like my Yubikey? How about
> a feature like GnuPG's group line or Enigmail's per-recipient rules?
> In-line PGP as well as PGP/MIME? Encrypted subject and the ability to
> turn it on or off? As far as I know, they are all features of GnuPG or
> Enigmail and not required by the OpenPGP specification.
>
> Patrick and company deserve our thanks for many years splendid service
> to the OpenPGP community. So does Werner and his team who created and
> maintain a tool that has satisfied a wide range of users for decades. I
> doubt that yet another proprietary OpenPGP system is what the world needs.

You are speaking out of my heart. Many years ago, I appreciated
Mozilla's decision to provide their own root certificates and
certificate management, because I trusted them much more than Microsoft.

But when it comes to PGP integration, making their own thing for sure is
counter-productive. What Werner and Patrick have created is mature and
completely trustworthy and surely can't be outranked in the foreseeable
time.

Not wanting to make users install additional software isn't a reasonable
argument for re-inventing the wheel, because AFAIK nothing prevents
people from bundling GnuPG with TB in the same installer, and I bet that
even installing these two packages into the same directory and letting
them use the same registry subkeys technically wouldn't be a problem (I
am speaking of Windows here).

So why not take Enigmail, integrate it into TB, and bundle Gpg4Win setup
with TB setup? All software they ever could develop themselves will be
inferior compared to that package, at least in the first time.

Regards,

Binarus

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Binarus wrote on 16.10.2019 10:47:
>
> On 14.10.2019 16:15, Jeff Allen via Gnupg-users wrote:
>>> I don't know either, but perhaps it is in the debug logs the Enigmail
>>> team analyzes?
>>
>> I have used Enigmail since its inception and have never knowingly
>> submitted a log or answered a survey and have always assumed Enigmail
>> does not phone home.
>
> I am sure that it doesn't phone home. However, to give an example, I had

You can be certain that I'd never implement that.
[...]
> I suppose that the Enigmail team gets quite a lot of such debug logs.
> But I still can't tell (and currently don't have the time to
> investigate) if those logs can tell which keys had been generated by
> Enigmail and which had been generated externally, so the whole thing was
> a guess anyway.

Yes, I did and do get quite a lot of debugging log files, and even more
support requests. And I really speak from experience when I say that the
vast majority of the users of Enigmail don't store their private keys on
external devices.

[...]

> So why not take Enigmail, integrate it into TB, and bundle Gpg4Win setup
> with TB setup? All software they ever could develop themselves will be
> inferior compared to that package, at least in the first time.

I have almost 17 years of experience with supporting Enigmail. About 90%
of all support requests that I get turn out to be setup issues with
GnuPG. Interestingly, most of them are on Linux, even though all Linux
distributions I know ship GnuPG. The bundling/shipping would not be a
worry for me. The main problem is the additional complexity that it
brings if you require an external component that you cannot *fully*
control. This covers topics like different behavior of different
versions, but also configuration issues, users rights to install
something on their PC and more. Gpgme may handle some of these issues,
but the fact remains: an external component makes things a lot more
complex, especially for support.

-Patrick

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Wed, 16 Oct 2019 13:07, Patrick Brunschwig said:

> something on their PC and more. Gpgme may handle some of these issues,
> but the fact remains: an external component makes things a lot more
> complex, especially for support.

Right GPGME handles this all pretty well and I have suggested often
enough that you should move to GPGME so that we can better support
Enigmail. Your comment about external components is right from a
company POV; however Enigmail is also an external component to TB and
thus TB suffers from very similar problem. GpgOL and GnuPG both are
maintained by us and thus I know very well this helps to reduce
friction.

The move to integrate OpenPGP in TB is important but also pretty risky
if it won't work for everyone right away from the start. The big
advantage of TB/Enigmail is that it is cross-platform and often the only
way to have encrypted mail on macOS. I know several media companies who
badly suffered when GpgTools were not able to get their plugin working
on a new macOS version. Their journalists were then forced to use TB
and not their, for whatever reason, beloved apple mailer. Let's hope
that at least of one is always working.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

On Wed, 16 Oct 2019 10:46, Martijn Brinkers said:

> I actually spend a lot of time investigating the impact of EFAIL on
> S/MIME and it's my opinion that the real impact has been overblown. In
> all my experiments, and I can tell you I have done a lot of them, I have
> not been able to force a mail client to actually forward the decrypted
> content to a remote system.

I recall that you mentioned this in the past and I have not seen any
statement to the contrary. In fact the whole attack is nearly 20 years
old and even back then it was hard to construct a case where the
non-authenticated encryption could be abused. When the PGP folks and me
discussed the attack around the year 2000, we knew that and suggested
signed mails as a solid counter-measurement. The MDC was then
introduced mainly to counter the more or less theoretical attack and to
be on the safe side in case better attacks would be developed.

The media and political coverage (we had working groups and internal
meetings) of the efail paper however required some extra measurements to
take.

> I think the problem with the paper was that they discusses two separate
> issues. The issue with Efail-2 was serious but that was more an mail
> client issue.

I fully agree here. As usual reports about the MUA failures spread for
months without mentioning that all the major MUAs fixed the bug within a
few days or weeks or even had fixed it at the time the paper was
published.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.