Subject: Re: [openpgp] Intent to deprecate: Insecure primitives

From: David Leon Gil <[email-masked]>
Date: Wed, 08 Apr 2015 15:32:07 +0000

Brief update on plans for deprecation: The tracking issue is at
https://github.com/yahoo/end-to-end/issues/31

Please feel free to open another issue if you have specific objections. I
will either be convinced by your arguments, and change the plan, or explain
why I don't.

On Mon, Mar 23, 2015 at 12:25 PM Christoph Anton Mitterer <
[email-masked]> wrote:

> On Tue, 2015-03-17 at 11:04 -0400, Derek Atkins wrote:
> > Show me an MUA that does this, please?  None of the OpenPGP-aware MUAs
> > I've ever used have this feature, as far as I know.  I suppose I could
> > go out of my way to replace the encrypted email with a
> > re-encrypted/plaintext email.
> >
> > But frankly I'd like my encryption software to just maintain the ability
> > to decrypt it later.
>
> While I don't think that implementations should throw away old algos
> (even if insecure) - the should just no longer use it for creating new
> content, and should only decrypt/verify signatures with appropriate
> warnings, I'd say that the question of long term storage of
> encrypted/signed content (e.g. mails) is (and should be) beyond the
> scope of OpenPGP.
> That being said, the WG shouldn't alter the decisions it makes based on
> that question, but rather only on security considerations.
>
>
> As for e.g. long term email storage:
> - if you just store them as received over the wire (i.e.
> encrypted/signed) they may very well become insecure over time, so the
> original purpose of confidentiality and authenticity is no longer
> guaranteed (by leaving them with the old encryption/signature).
>
> - constantly re-encrypting them seems to be not feasible, and you cannot
> re-sign mails from someone else.
>
> - IMHO the appropriate way would be for a MUA to record that the mail
> was sent encrypted to you and by whom of your contacts it was signed (if
> any of that was the case) - for later reference.
> And any further protection of the content should be handled by disk
> encryption.
>
>
> Cheers,
> Chris.
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Wed, 08 Apr 2015 20:36:28 +0200

On Wed, 2015-04-08 at 15:32 +0000, David Leon Gil wrote:
> Please feel free to open another issue if you have specific
> objections. I will either be convinced by your arguments, and change
> the plan, or explain why I don't.

Look, as I've pointed out previously, I personally think that crypto,
done as a web app is inherently untrustworthy.

Maybe I just got something wrong, but AFAIU the idea of "e2e" projects
like your's is to add e2e crypto into your webapps, e.g. via javascript.
Thus the software doing crypto is each time downloaded again from the
server by the client, right?
So ultimately control is again fully at the vendor (at any time he could
send other code and no one would notice), and fully dependent on a
working https (which is as we should all know by now inherently insecure
due to the issues of the CA system).

So to me, the whole e2e crypto campaigns run by some of the bigger
vendors is just a marketing thing, at best.
Actually, if I'd be part of organisations doing mass surveillance,
fearing that people could now switch to properly used crypto, then these
would be the two things I'd tried to do as a countermeasure:
- TOFU
and
- propagating actually weak e2e crypto systems on a broad scale, giving
people a wrong sense of being secure[0].

That being said, at least I probably won't focus myself on what Yahoo,
Google or any other big company does.
Looking at the the ticket you mention, *some* things you plan to
deprecate are definitely a good idea, for others I'd see simply no good
reason that anyone would follow these now. Especially some of the
"eventually" things seem a bit crude.
And I guess my personal opinion about algorithm diversity is known as
well.

But more important:
Implementations have always been free to implement what they like (even
if, strictly speaking, they may have lost the status of a conforming
implementation). But you shouldn't expect that others follow your steps,
just because big-company-xyz is doing so now.

However, the more you depart from "standard" usage of OpenPGP, the more
you should probably call it something else.
This would especially apply for anyone who would think he drives the
standardisation process and not the community of real/serious OpenPGP
users.

And even more important, none of the big companies which add that IMHO
at best questionable web-based e2e crypto to their services, should
expect that this would make them represent the majority of OpenPGP users
and thus would give them a strong voice in decisions.
Just because e.g. google would automatically enable questionable e2e
crypto for millions of their gmail users, doesn't mean that one as a
real "legitimate" OpenPGP user base there.

For all the above reasons, I personally feel, that it's not appropriate
here at the OpenPGP WG list, to discuss single unilateral decisions made
by an OpenPGP implementation[1].

If one says "hey, let's discuss whether we should deprecate twofish in
OpenPGP" that's totally fine,... but informing the standardisation body
"hey we drop now support for x, y and z" with an implicit "and since we
represent n users, you better follow our decision" is not appropriate.

Cheers,
Chris.

[0] Ever wondered why nearly each totalitarian regime still carries out
elections? It still gives people a little feeling of having choice.
[1] And exception might be GnuPG, simply because *it* likely actually
represents the majority of all serious users of OpenPGP.

---

From: ianG <[email-masked]>
Date: Fri, 10 Apr 2015 17:46:15 +0100

> done as a web app is inherently untrustworthy.

Which is out of scope for this list, right?

> represent n users, you better follow our decision" is not appropriate.

I saw no such implication.  I personally appreciate it when vendors 
actually do tell us what they are doing when that effects the way many 
users are going to be using the product.  In our fishbowl, we sometimes 
lack the context of what happens out in the field, so news of that 
nature - hopefully concise and clear - is welcome.  To me at least.

iang

---

From: Tom Ritter <[email-masked]>
Date: Sat, 11 Apr 2015 09:30:05 -0500

> server by the client, right?

No. Most (and by most I mean the more high-profile ones that try to do
it as correct as possible[0]) have moved virtually all operations into
a browser extension.  It is downloaded and installed once, updated
based on how the browser updates extensions, and (for better or worse)
mediates through a third party (the browser's add store) to prevent
individual targeting of users by the plugin author.

> due to the issues of the CA system).

No, as above, and regarding the CA system - Which itself is addressed
by some projects and services using HPKP.

> Which is out of scope for this list, right?

Agreed. But I feel compelled to correct factual inaccuracies.

> I saw no such implication.  I personally appreciate it when vendors actually
> do tell us what they are doing when that effects the way many users are
> going to be using the product.  In our fishbowl, we sometimes lack the
> context of what happens out in the field, so news of that nature - hopefully
> concise and clear - is welcome.  To me at least.

Double agreed.  I wouldn't want a working group to be an -announce
list of product releases, but since I literally found a completely new
OpenPGP plugin yesterday (gpg4o), I'm happy to read concise reports on
how different plugins/tools operate at the standard layer, and that
nebulous 'above-standard' layer like PGP/MIME quirks.  One day one of
them may help me figure out how my Outlook server is broken wrt to
mac's gpgtools and some-but-not-all other PGP clients.

-tom

[0] Yahoo and Google's E2E, CryptoCat, Mailvelope

---

From: Ben McGinnes <[email-masked]>
Date: Sun, 12 Apr 2015 05:45:34 +1000

> due to the issues of the CA system).

Yes, that's precisely the case and in the OpenPGP world we've already
seen precisely this situation occur with Hushmail.  IIRC it was at the
insistence of the FBI that they replaced bits of their code in order
to harvest passphrases and access messages.

Even with private keys on the user's system it still wouldn't take too
much more to compromise the system given enough pressure from a third
party (i.e. government) source.

> real "legitimate" OpenPGP user base there.

Damn straight.  I note, for example, that my key would be arbitrarily
not supported by the proposed model simply for including an ELG-E
subkey with the RSA master key for no apparent reason.  Well,
presumably the reason is Yahoo! doesn't want to pay people to write a
solid enough implementation that they can actually use without
breaking some kind of license.  I suspect the same is true with
regards to TWOFISH since, even though THREEFISH exists, there's been
no indication that it is broken or ought to be deprecated.

> represent n users, you better follow our decision" is not appropriate.

Absolutely.

Regards,
Ben