Subject: [openpgp] Intent to deprecate: Insecure primitives

From: David Leon Gil <[email-masked]>
Date: Fri, 13 Mar 2015 18:22:34 -0700

First, the fait accompli:

1. Yahoo and Google have both already deprecated and removed support
for the following packet type specified for use with OpenPGPv4:

    Tag 9 (symmetrically encrypted) packets

These packets provide unauthenticated encryption and -- if supported
-- can be used in a downgrade attack on senders who only use SEIPD
packets. See https://github.com/coruus/cooperpair/tree/master/encrux
for details.

2. Yahoo and GnuPG have both already deprecated V3 public keys for any
use. We recommend that other implementations do the same.

--

Second, the near future:

Yahoo has deprecated, and intends to disable support for all uses, of
the following primitives and packet types specified for use with
OpenPGP v4:

- Symmetric cipher algorithms: IDEA, TDES, CAST5, Blowfish, Twofish
- Asymmetric algorithms, generally: RSA-ES, DSA.
- Asymmetric algorithms, unless > 3070 bit key length: RSA-S, RSA-E, ELG-E.
- Compression algorithms: ZLIB. (It provides no benefits over DEFLATE,
and is more malleable.)
- Hash algorithms: MD5, SHA-1, RIPEMD160, SHA-2-224.

We do not, at present, support any of the CAMELLIA algorithms or
BZIP2. It is unlikely that we will do so in future.

At present, we anticipate removing support for these primitives no
later than May 1, 2015.

-- 

Third, other things that will be deprecated soonish:

1. Inconsistent combinations of primitives. In particular, it is
likely that we will not support RFC 6637 keys or packets unless they
conform to the 128-bit or 192-bit subprofiles specified in that
document. (We do not at present support P-521, but if we add support
for that, we would support an analogous "256-bit" subprofile.)

2. AES-128. The efficiency of multi-target attacks leaves no safety
margin for cryptanalysis. The performance difference between AES-128
and AES-256 on typical messages is negligible.

--

Finally, other things that may eventually result in messages or keys
being treated as invalid:

1. A published public key that is more than 1 year old. (This is
mainly taken care of by requiring > 3070 bit RSA keys...)
2. Signature by a public key which has ever signed a message or key
using MD-5 or SHA-1.
3. A compressed or literal data packet tag that is unusually formatted.
4. A compression method other than "Uncompressed".

David Leon Gil
Senior Paranoid
Yahoo!

---

From: Falcon Darkstar Momot <[email-masked]>
Date: Fri, 13 Mar 2015 18:30:36 -0700

Yes, I can get behind that.  Make it so!  Users should be presented with
secure defaults and not given the opportunity to unknowingly decrease
security.  Deprecating lower-security but equivalently performant
algorithms is especially commendable.

That said, archived encrypted data may require decryption support well
into the future.  OpenPGP-encrypted data is not ephemeral like
TLS-encrypted data.

--Falcon Darkstar Momot
--Shadytel

---

From: David Leon Gil <[email-masked]>
Date: Fri, 13 Mar 2015 21:54:36 -0700

> into the future.  OpenPGP-encrypted data is not ephemeral like

I agree: But note that it's possible to run, for example, programs
written for the Symbolics Lisp machine (c. 1982) on your Macbook Pro
today: https://github.com/ynniv/opengenera

And older versions of GnuPG are certainly still buildable! (As, I
anticipate, older versions of any extension will be.)

W.r.t. long-term storage of messages, however, I tend to think that
storing them in their wire format is exactly the wrong thing to do. If
you don't discard wire-format messages, you don't get PFS, even using
ephemeral-static ECDH.

---

From: Werner Koch <[email-masked]>
Date: Sat, 14 Mar 2015 13:04:39 +0100

> use. We recommend that other implementations do the same.

Only for GnuPG-2.  We keep on maintainog 1.4 so that existisng dat dan
still be decrupted.

> the following primitives and packet types specified for use with

This is what the preference system is all about.

Shalom-Salam,

   Werner

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

---

From: Wyllys Ingersoll <[email-masked]>
Date: Sat, 14 Mar 2015 13:18:03 +0000

Im all for deprecating and/or outright dropping of support for older
ciphers, it needlessly complicates the code and testing matrix, even if
they are optional to implement.   Frankly, very few people actually use,
say, CAMELLIA, in the wild.  I don't think anyone would notice if it
disappeared tomorrow.

However, if you get really restrictive (from your "eventual" list below)
and cut off support for common key sizes like 2048-bit RSA or keys that are
> 1 year old, you risk cutting off a huge chunk of the active OpenPGP user
base.  People are very reluctant to give up or create new keys once they
have distributed they public key to others, even if said key is old and
weak, unfortunately.  Updating existing keys (revoking sigs/keys, adding
new subkeys, etc) is considered black magic and far too complicated for
most casual users.  Though perhaps that issue could be solved by
streamlining the process in the various implementations. Im not sure the
usability issue can be solved by the standard itself.

If the goal is to increase the use and popularity of OpenPGP, locking out a
significant number of current users seems counterproductive.   Obviously,
that would be an implementation and business decision for Yahoo! and Google
to make in their codebase and not really relevant debate for this WG...

-Wyllys Ingersoll

On Fri, Mar 13, 2015 at 9:23 PM David Leon Gil <[email-masked]> wrote:

> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 16 Mar 2015 00:05:07 -0400

Hi David--

Thanks for this detailed list.  I agree with the intent to strip down
OpenPGP into a manageable and sensible profile, and i think the choices
you're documenting here are generally good.  A few clarifications and
questions below.

> packets. See https://github.com/coruus/cooperpair/tree/master/encrux

Just to clarify: SEIPD packets are tag 18 packets, which have
"integrity-protection" included:

 https://tools.ietf.org/html/rfc4880#section-5.13

> - Asymmetric algorithms, generally: RSA-ES, DSA.

Are you referring to Public Key Algorithms specifically here?  in
particular, this table:

 https://tools.ietf.org/html/rfc4880#section-9.1

If so, RSA-ES (pubkey algorithm 1) is very widely used, even for keys
that are only marked for one usage (signatures or encryption).  In fact,
i don't think there are many RSA keys labeled RSA-E (algo 2) and RSA-S
(algo 3) at all.  Why treat RSA-ES separately for deprecation?

On a relatively up-to-date keyring with a couple-thousand OpenPGP
certificates, i did this check (the first column is the count, the
second column is the algorithm ID):

0 foo@bar:~$ gpg2 --list-keys --with-colons | awk -F :  '/^[ps]ub:/{ print $4 }' | sort | uniq -c 
   2955 1
   1766 16
   1648 17
      2 18
      3 19
     19 20
      2 22
0 foo@bar:~$ 

> - Asymmetric algorithms, unless > 3070 bit key length: RSA-S, RSA-E, ELG-E.

How did you choose this cutoff?  I'm happy to see a high bar personally,
but this is likely to invalidate many 2048-bit keys that people have
been generating with (e.g.) the GnuPG defaults today.  Do you think that
GnuPG should change its defaults to the higher cutoff?

> - Compression algorithms: ZLIB. (It provides no benefits over DEFLATE,

Why keep DEFLATE at all?  quining seems to be possible with DEFLATE as
well.  what if we yanked all compression at this layer?

 (on openpgp quining due to compression, see the 2013-10-08 entry at
  http://mumble.net/~campbell/blag.txt)

> - Hash algorithms: MD5, SHA-1, RIPEMD160, SHA-2-224.

The OpenPGPv4 fingerprint uses SHA-1, in a way that doesn't appear to be
cryptographically risky; i'm assuming you're not removing v4
fingerprints entirely, just SHA-1 as a digest algorithm for message
signing.  right?

> mainly taken care of by requiring > 3070 bit RSA keys...)

Can you say more about this?  Is this about a specific cutoff in time,
or *anything* that is "more than 1 year old" at the present?  If it's
the latter, what effect do you expect this kind of regular key rollover
will have?  why is it warranted?

> 2. Signature by a public key which has ever signed a message or key

How would you tell if this is the case?  Isn't ignoring MD5 and SHA1
signatures itself sufficient?

     --dkg

---

From: Kristian Fiskerstrand <[email-masked]>
Date: Mon, 16 Mar 2015 09:59:10 +0100

>> 
>> - Symmetric cipher algorithms: IDEA, TDES, CAST5, Blowfish,
>> Twofish - Asymmetric algorithms, generally: RSA-ES, DSA.
> 
> If so, RSA-ES (pubkey algorithm 1) is very widely used, even for
> keys that are only marked for one usage (signatures or encryption).
> In fact, i don't think there are many RSA keys labeled RSA-E (algo
> 2) and RSA-S (algo 3) at all.  Why treat RSA-ES separately for
> deprecation?
> 

Just to add a bit more data to this, on a keyserver (a hockeypuck
instance not supporting ECC) the corresponding figures (primary +
subkey) for 3882360 primary keys and 3612096 subkeys shows.

- -----------+---------
        16 | 2658039
         1 | 2185612
         3 |     627
        17 | 2649388
         0 |     196
         2 |     594

(this is not adjusting for revoked / expired keys etc)

On an older copy (around January 2014, this time dumped from SKS
supporting ECC) with 3532268 primary keys and 3288749 subkeys, but it
shows a bit of the trend

+------+----------+
| algo | COUNT(1) |
+------+----------+
|    0 |      352 |
|    1 |  1552104 |
|    2 |      341 |
|    3 |      371 |
|   16 |  2636715 |
|   17 |  2629639 |
|   18 |       37 |
|   19 |       44 |
|   20 |     1380 |
|  101 |        2 |
|  103 |       32 |
+------+----------+
11 rows in set (3.76 sec).

If interesting I can always do a refreshed dump from SKS also adding
support for Ed25519 (experimental), if tracking the development of
number of keys here is of interest.

> How did you choose this cutoff?  I'm happy to see a high bar
> personally, but this is likely to invalidate many 2048-bit keys
> that people have been generating with (e.g.) the GnuPG defaults
> today.  Do you think that GnuPG should change its defaults to the
> higher cutoff?

And if believing so, what rationale is behind this?

- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Nosce te ipsum!
Know thyself!

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Mar 2015 10:46:43 +0000

(with no hats)

On 16/03/15 04:05, Daniel Kahn Gillmor wrote:
> I'm happy to see a high bar personally, but this is likely to
> invalidate many 2048-bit keys

My experience is that it's far far easier to deprecate
things that only have an effect in-line compared to wanting
to invalidate long term things like key values, esp.
public key values that are distributed around the Internet.

So even if one would like to do the latter then I think
it'd be a really good plan to separate that part of the
argument as it's likely to be much trickier. We had a
similar set of issues as we transitioned from DomainKeys
to DKIM - in that case the proponents of DomainKeys
were (correctly) extremely reluctant to break the few
deployments that were then-current. And I think we got
that right in that the WG changed the wire-formats and
signature algorithm requirements but in such a way that
already-deployed public keys continued to work.

I'd also note that we ought be cognizant that the fall
back here is e2e plaintext. If one considers RFC7435
then I think there's an argument to be considered for
allowing crypto that is perhaps approaching it's
sell-by date but that is clearly not yet past it's
use-by date. (And of course one can have fine arguments
about both dates;-) And if we wanted to invalidate
current keys, then I think that also puts an onus on
us to consider how to figure out the migration path
from working->broken->working-again.

Lastly, I'd note that e2e email security is a thing
where we (IETF and the broader tech community) have
failed pretty consistently because we made it too hard.

By failed, I mean e2e security is not something that is
commonly used by billions of folks. Part of that is UI,
but some of it is IMO also because we chose to try to
gold-plate security which made usability even worse. I
think the classic example with smime was requiring a
certificate before anything works - while such decisions
may have made sense for the 1990's enterprise, they
do not make sense in today's environment. So I think we
should be very wary of failing again through attempting
to gold-plate by mandating less commonly supported (by
dev. environments) algorithms or keys.

If there's a real need to invalidate old keys then let's
see that technically justified and if we must, then try
do that in a way that brings along the few million current
users rather than in a way that locks those out.

But I'm not yet convinced that there really is such a
need.

S.

---

From: Derek Atkins <[email-masked]>
Date: Mon, 16 Mar 2015 09:51:35 -0400

> Only for GnuPG-2.  We keep on maintainog 1.4 so that existisng dat dan

Yeah, I'm still a bit bitter about that.. ;-)

It means I need to keep two versions around and somehow get my mailer
to know which one to use when I want to go through my historical
encrypted email archives.

Oh, you expected me to decrypt/re-encrypt my encrypted email as I got it???

> This is what the preference system is all about.

Indeed.

>    Werner

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Stephen Paul Weber <[email-masked]>
Date: Mon, 16 Mar 2015 09:49:34 -0500

>(algo 3) at all.  Why treat RSA-ES separately for deprecation?

In fact, aren't the RSA-E and RSA-S algorithms basically just historical 
/ mostly deprecated in favour of marking keys for a particular use?

---

From: David Shaw <[email-masked]>
Date: Mon, 16 Mar 2015 10:56:13 -0400

On Mar 16, 2015, at 10:49 AM, Stephen Paul Weber <[email-masked]> wrote:
> In fact, aren't the RSA-E and RSA-S algorithms basically just historical / mostly deprecated in favour of marking keys for a particular use?

Yes.  If I recall, they predate the "key flags" method of indicating the intended purpose of a key.  4880 makes them SHOULD NOT generate, but implementations are allowed to interpret them if they want to (I'd assume as a type 1 RSA key with an implicit key flags saying encrypt-only or sign-only, but that's just my reading).

David

---

From: Bill Frantz <[email-masked]>
Date: Mon, 16 Mar 2015 09:35:55 -0700

>Oh, you expected me to decrypt/re-encrypt my encrypted email as I got it???

For many uses, decrypting from the wire format and re-encrypting 
in the "data at rest" security format makes excellent sense. 
Having only one encryption scheme for long-term storage allows 
easy (relatively) upgrade and helps to ensure that the data is 
still accessible, i.e. the decryption still works. I probably 
have a bunch of old PGP encrypted email I can't read anymore 
because I don't have the secret key, or its passphrase. If that 
mail had been re-encrypted in a format that I decrypt every day, 
I would still be able to read the mail. Encryption that isn't 
regularly exercised gets rusty.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | If the site is supported by  | Periwinkle
(408)356-8506      | ads, you are the product.    | 16345 
Englewood Ave
www.pwpconsult.com |                              | Los Gatos, 
CA 95032

---

From: [email-masked]
Date: Mon, 16 Mar 2015 13:18:32 -0400

On 3/15/2015 at 11:56 PM, "Daniel Kahn Gillmor" <[email-masked]> wrote:

>Twofish

-----

All previous OpenPGP have had a MUST implement for 3DES.
Is there any advantage in using only block 64 symmetric encryption primitives, to do away with 3 DES, IDEA and CAST 5?

In general, won't removing these primitives make it difficult to decrypt past correspondences where people have used these primitives?
(The default for symmmetrically encrypted GnuPG messages has been CAST5 for a long time in the past, -i.e. many many encrypted messages ...)

vedaal

---

From: Jon Callas <[email-masked]>
Date: Mon, 16 Mar 2015 13:10:57 -0700

> On Mar 16, 2015, at 7:49 AM, Stephen Paul Weber <[email-masked]> wrote:
> 

Yes. They were essentially historical even in RFC 1991 days.

	Jon

---

From: David Leon Gil <[email-masked]>
Date: Mon, 16 Mar 2015 14:00:57 -0700

On Monday, March 16, 2015, Jon Callas <[email-masked]> wrote:

>
> > On Mar 16, 2015, at 7:49 AM, Stephen Paul Weber <
> [email-masked] <javascript:;>> wrote:
> >

My impression was that many new implementations use the RSA-S and RSA-E
algorithms for signing keys and encryption subkeys. But -- taking a look at
SKS numbers --algorithm 1 is used quite a lot.

I generally prefer domain separation, but I don't think there's a relevant
security difference *so long as* implementations do not generate a single
RSA key such that its key usage intersects only one of {certify, sign,
authenticate} or {encrypt communications, encrypt bulk}.

(And so, in the eventual I-D, I'll likely make that the requirement. I
would be inclined, in that case, to state that implementations SHOULD
accept any of algorithms 1, 2, 3 for any usage mask valid under the
above criterion.)

---

From: David Leon Gil <[email-masked]>
Date: Mon, 16 Mar 2015 14:09:58 -0700

On Monday, March 16, 2015, <[email-masked]> wrote:

> On 3/15/2015 at 11:56 PM, "Daniel Kahn Gillmor" <[email-masked]
> <javascript:;>> wrote:
>
> Is there any advantage in using only block 64 symmetric encryption
> primitives, to do away with 3 DES, IDEA and CAST 5?

Yes re block size  (I'm assuming you meant 128-bit blocksize ciphers). A
64-bit blocksize is small enough that there is a significant probability of
(some user) encrypting a message with two blocks the same.

CAST5 (CAST128), however, is a 128-bit blocksize cipher.

In general, won't removing these primitives make it difficult to decrypt
> past correspondences where people have used these primitives?
> (The default for symmmetrically encrypted GnuPG messages has been CAST5
> for a long time in the past, -i.e. many many encrypted messages ...)
>

Yes. GnuPG's use of CAST5 is problematic. We won't support this usage for
encryption or decryption. (Mainly because it did so if you didn't set a
'modern' cipher, and thus didn't use the SEIPD+MDC packet.)

Other implementations are free to; they really shouldn't be encrypting new
messages using it.

I will note that the Canadian government still permits the use of CAST5 for
the encryption of data at a 128-bit security level, but requires a
cryptoperiod of < 7 days. (Which is not terrribly reassuring.)

See https://www.cse-cst.gc.ca/en/node/227/html/15164

---

From: David Leon Gil <[email-masked]>
Date: Mon, 16 Mar 2015 14:11:33 -0700

On Monday, March 16, 2015, Bill Frantz <[email-masked]> wrote:

> [...] I probably have a bunch of old PGP encrypted email I can't read
> anymore because I don't have the secret key, or its passphrase. If that
> mail had been re-encrypted in a format that I decrypt every day, I would
> still be able to read the mail.

Yep. Same boat here, actually. I think this is something that is better for
security and better for usability.

---

From: Stephen Paul Weber <[email-masked]>
Date: Mon, 16 Mar 2015 16:15:18 -0500

>My impression was that many new implementations use the RSA-S and RSA-E

The opposite is true.  RSA-S and RSA-E are from old implementations.  These 
days there are more robust ways to specify what a key is for.

>authenticate} or {encrypt communications, encrypt bulk}.

For sure, but this seperation is done in metadata, not in the algorithm 
identifier.

-- 
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph

---

From: David Shaw <[email-masked]>
Date: Mon, 16 Mar 2015 17:17:27 -0400

On Mar 16, 2015, at 5:00 PM, David Leon Gil <[email-masked]> wrote:
> My impression was that many new implementations use the RSA-S and RSA-E algorithms for signing keys and encryption subkeys. But -- taking a look at SKS numbers --algorithm 1 is used quite a lot.

Having a lot of algorithm 1 makes sense: RSA-S and RSA-E are deprecated, and were made "SHOULD NOT" create in 4880, in favor of using the key flags subpacket to indicate usage.  I don't know of any current implementations that use RSA-S or RSA-E for new keys.

David

---

From: David Leon Gil <[email-masked]>
Date: Mon, 16 Mar 2015 14:40:52 -0700

> (algo 3) at all.  Why treat RSA-ES separately for deprecation?

You're quite right; this was a mistake.

> GnuPG should change its defaults to the higher cutoff?
Page 22 of the ENISA key-length report has a summary of recommendations.
The (NSA-written) NIST standard in this area requires 3072-bit keysize for
128-bit security. Other sources require much longer keys.

Yes, I think that GnuPG should change its defaults; I think that 128-bit
security is the bare minimum threshold for security.

> well.  what if we yanked all compression at this layer?

I'd be happy to.

>   http://mumble.net/~campbell/blag.txt)

Thanks for the link. There are a lot of problems with doing compression and
encryption, especially with a block-chaining mode...

I'd be quite happy to deprecate everything but uncompressed.

> fingerprints entirely, just SHA-1 as a digest algorithm for message

Well, I'm not a great fan of v4 fingerprints or the SEIPD+MDC mode, but
yes: That list only refers to usage for signatures.

> will have?  why is it warranted?

Sure. How many days since the last zero-day security vulnerability on the
computer you are using? (Hopefully you're using something awesome with
grsecurity etc., but most users aren't.)

It will be a rolling cut-off. (In future, it is possible that there may be
some non-user-circumventable prohibition on reusing RSA moduli, in
particular.)

(This applies, but with somewhat less force, to most hardware-protected
keys: It is likely that they have been used often enough that more
sophisticated attacks are likely to have been able to recover the key. And
if you're using hardware protection, you are probably a likely target of
attackers with these capabilities.)

> signatures itself sufficient?

An exported key, for example, may have a subkey which it has signed using
MD5. I consider this to invalidate the signing key.

A brief description of the (tentative) algorithm: Attempt to import an
importable public key. If any signature packet in the composition uses a
weak hash algorithm, reject the importable key in its entirety.

---

From: Ryan Carboni <[email-masked]>
Date: Mon, 16 Mar 2015 15:24:56 -0700

I suggest Threefish. It is (practically) immune to the risk of collisions
revealing plaintext in CFB mode, and is slightly more secure. It's probably
best to use the version of Threefish before they increased the number of
rounds to deal with collisions.

---

From: Jon Callas <[email-masked]>
Date: Mon, 16 Mar 2015 15:48:03 -0700

> On Mar 16, 2015, at 3:24 PM, Ryan Carboni <[email-masked]> wrote:
> 
> I suggest Threefish. It is (practically) immune to the risk of collisions revealing plaintext in CFB mode, and is slightly more secure. It's probably best to use the version of Threefish before they increased the number of rounds to deal with collisions.

As a Threefish co-author, thank you for your vote of confidence.

We never increased the number of rounds. We tweaked constants, but that's all.

Threefish is a wide-block, tweakable block cipher and would need a small bit of description of how to use it; it's not a drop-in replacement for something like AES.

But I'd be happy to do that, myself, and could make suggestions in less than a paragraph.

	Jon

---

From: Werner Koch <[email-masked]>
Date: Tue, 17 Mar 2015 12:44:48 +0100

> CAST5 (CAST128), however, is a 128-bit blocksize cipher.

Nope.  CAST5-128 as used by OpenPGP is a 64 bit block size cipher.

> Yes. GnuPG's use of CAST5 is problematic. We won't support this usage for

Must be a pretty old version which defaults to CAST5.  But what is
problematic with CAST 5 given that it is one of the two SHOULD ciphers
in OpenPGP?

Salam-Shalom,

   Werner

---

From: Derek Atkins <[email-masked]>
Date: Tue, 17 Mar 2015 11:04:46 -0400

Bill Frantz <[email-masked]> writes:

> For many uses, decrypting from the wire format and re-encrypting in
> the "data at rest" security format makes excellent sense. Having only
> one encryption scheme for long-term storage allows easy (relatively)
> upgrade and helps to ensure that the data is still accessible,
> i.e. the decryption still works. I probably have a bunch of old PGP
> encrypted email I can't read anymore because I don't have the secret
> key, or its passphrase. If that mail had been re-encrypted in a format
> that I decrypt every day, I would still be able to read the
> mail. Encryption that isn't regularly exercised gets rusty.

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.

-derek

---

From: Bill Frantz <[email-masked]>
Date: Tue, 17 Mar 2015 15:11:57 -0700

>re-encrypted/plaintext email.

I was thinking of the system level disk encryption for the data 
at rest. It is available for most systems these days.

>But frankly I'd like my encryption software to just maintain the ability

Well, the problem isn't the software. It is the user.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | I don't have high-speed      | Periwinkle
(408)356-8506      | internet. I have DSL.        | 16345 
Englewood Ave
www.pwpconsult.com |                              | Los Gatos, 
CA 95032

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 17 Mar 2015 21:05:59 -0400

Thanks for the response and the clarifications, David!  More discussion
below...

On Mon 2015-03-16 17:40:52 -0400, David Leon Gil wrote:
> On Sunday, March 15, 2015, Daniel Kahn Gillmor <[email-masked]> wrote:
>> [David Leon Gil wrote:]

This threat analysis might be too narrow: it focuses only on exploitable
software flaws and cryptanalytic attacks, but it omits human factors.  I
worry that acting on it might open up new vectors of attack.

Key continuity is valuable, and understanding how to deal with key
transitions is hard for most end users.  If key transitions happen
regularly and we have no way of surfacing them to the user in a
meaningful, then we have introduced a simple key replacement attack
opportunity for *every* user that comes up at least once a year.  That's
quite a bit cheaper to carry out than factoring a 3072-bit RSA modulus
;)

I can strawman a few approaches to address this without requiring users
to become experts in distinguishing legitimate from fraudulent key
transitions:

 0) subkeys: allow older primary keys, but expect subkeys to be rotated
    regularly, and do not accept regular message signatures from primary
    keys (make them certification-only).  This yields a known key
    migration pattern that can be cryptographically checked.
    Cryptographic certifications by third-parties are made to the
    primary key itself, so those certifications will last (for users who
    want to rely on them) even across subkey rotation.  This approach
    also encourages the use of offline primary keys, which might help
    UI/UX people focus on improving that workflow.  It also works
    entirely with the specs as we know them.

 1) chained primary keys: in this approach, we'd have a primary key that
    gets used for a limited time period (your "one year" cutoff, say),
    but at the end of that time period can certify a replacement primary
    key.  This is a bit more awkward with current tools, but we can
    always build extra tooling.  It also seems unclear how to find the
    new key after a two-period gap: that is, if i know you have key X_0,
    you then replace it with X_1 (certified by X_0, among others), and
    then again with X_2 (certified with X_1, among others), what tooling
    do i use to build the chain?  How do third-party certifications
    persist in this context?  (or do we give up on persistent
    third-party certifications entirely?)

 2) expose key transitions in a way that people can easily understand
    them and distinguish "legit" from "fraudulent"?  I don't even know
    what this would look like, but it smells like it would create a
    serious support burden for any large organization that tried to roll
    it out, as some vocal minority of users will misunderstand and freak
    out thinking that they've been targeted somehow during a standard
    key transition.  We've discussed this situation on the
    [email-masked] list some, with no good proposals i've
    seen other than "rely on your e-mail provider for key continuity".
    But if your provider can swap out your key every year for some other
    key and everyone will accept it, then the "e2e" principle seems to
    be weaker than we'd like.

 3) hope that key transitions somehow won't be an issue or a point of
    weakness?  Not sure how to justify this, but if someone can paint
    this picture convincingly, i'd be a happy camper...

Any other thoughts?

> MD5. I consider this to invalidate the signing key.

Why does this invalidate the signing key?  I wouldn't be willing to rely
on the MD5 *signature*, but I don't see why it would invalidate the
entire key, or any signature made over a better algorithm.

The implication seems to be that there is some sort of cross-hash attack
against signatures, like: if you can convince me to sign something with
MD5, then you can craft some phoney signature over an SHA256 digest.

But if this is true (i'm unaware of such an attack), then maybe it's
also true the other way around: if you can convince me to sign something
with SHA256, then maybe you can craft some phoney signature over an MD5
digest.  If this is possible, then you can invalidate my key by
demonstrating an MD5 signature.  this is a surprising outcome!

I think it makes more sense to just ignore signatures over weak digests
than to discard a key that uses a weak digest.

> weak hash algorithm, reject the importable key in its entirety.

This algorithm sounds very risky.  Not every signature in an importable
public key (i prefer the term "OpenPGP certificate") is made by the
public key in the certificate.  I don't think you'd want to reject a key
on the basis of a third-party certification that happens to be in the
certificate.

Also, what if a certification uses an unknown digest algorithm -- this
could be a good algorithm or a bad algorithm, but you don't know which.
It's safest to treat the certification as a bad algorithm, but the right
thing to do in either case is to ignore the certification, but not to
ditch the certificate entirely.

An OpenPGP certificate, once stripped of certifications made over weak
algorithms, still needs to have certain properties (like a
self-certification from the primary key over itself and a User ID).  If
those properties aren't met, then yes: ditch the certificate entirely.
Otherwise, keep the pruned certificate.

wdyt?

           --dkg

---

From: Falcon Darkstar Momot <[email-masked]>
Date: Wed, 18 Mar 2015 01:21:33 -0600

I'm not sure this approach scales.

More importantly, I'm not sure it's common practice.  The IETF is at its
best when it is codifying existing practice to promote interop, not when
it's trying to radically change practice with fairly onerous new
recommendations.

Perhaps if anyone desires to modify practice, they should start by
promoting their new approach so that multiple software platforms and the
reference implementation support it.  Perhaps modifications to
open-source mail clients to support a distinction between "wire format"
and "data at rest" and an encryption rollover format would be useful.

On 16/03/2015 10:35, Bill Frantz wrote:
> upgrade and helps to ensure that the data is still accessible, i.e.
> the decryption still works. I probably have a bunch of old PGP
> that I decrypt every day, I would still be able to read the mail.
> Encryption that isn't regularly exercised gets rusty.
>
> Cheers - Bill
>
> (408)356-8506      | ads, you are the product.    | 16345 Englewood Ave
> www.pwpconsult.com |                              | Los Gatos, CA 95032
>

---

From: Falcon Darkstar Momot <[email-masked]>
Date: Wed, 18 Mar 2015 01:23:36 -0600

No!  This is the kind of attitude that got OpenPGP into its current
usability mess!

On 17/03/2015 16:11, Bill Frantz wrote:
> (408)356-8506      | internet. I have DSL.        | 16345 Englewood Ave

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Mar 2015 09:36:49 -0400

> But frankly I'd like my encryption software to just maintain the ability

The only thing I have seen done that is similar is re-signing documents
under a stronger signature key. But that is now obsolete since the
Harber-Stornetta patents expired and hash chain type schemes are possible.

We have considered the underlying problem quite a bit on the cryptography
list. There are many problems of key management. For example, do I want
people to be able to read some of my emails on death? In an enterprise
scenario, I don't want the bank to lose all the emails I sent to my broker
because she fell under a bus.

There are also many complicating factors. Phones get stolen or lost, etc.
etc.

This led me to an approach in which each user has a personal PKI hierarchy.
This is probably going to look excessive. But solving the use cases
requires every bit. If you want to be able to have some part of your
communications be proof against court warrants, you need more.

1) A personal offline key signing key. [R]
2) A personal offline recovery encryption key. [R]

3) A personal online key signing key with expiry ~ 10 years
4) A personal mail encryption key [R] that is rotated monthly and escrowed
under the personal offline recovery encryption key.

In addition each device has a personal message signing key and a key
distribution key that are unique to that device and never leave it.

So in PRISM-PROOF, the standard configuration begins with six keygens(!)

The keys marked [R] may have recovery support. To do this we encrypt the
message and store the bits in the cloud. This means we only need to escrow
the decryption key somehow. In the case of (1) and (2) this is done with
key shares printed out onto paper (and as QR codes). In the case of (4) the
key is escrowed under key (2).

Each key is wrapped in X.509. Yes, I hate it as much as anyone else. But
doing that allows me to use the keys in S/MIME and enroll them in TRANS
logs.

Yes, there is a lot of complexity. But the user does not see any of it. I
would rather have more code complexity than user experience complexity.

The user's fingerprint is the hash of (1) which is intended to be
potentially a life long master key. By which I mean that it should work for
a person's whole life though it is possible it might be superseded in
certain circumstances.

Now this is probably not something people want to be thinking about in
OpenPGP vNext. But it is something you might want to consider as a future
convergence possibility.

---

From: Bill Frantz <[email-masked]>
Date: Wed, 18 Mar 2015 15:38:59 -0700

The software works fine. The user has either lost the secret key 
file or has forgotten the passphrase. I don't know a technical 
solution, particularly to the 2nd problem. Any suggestions?

Cheers - Bill

On 3/18/15 at 12:23 AM, [email-masked] (Falcon Darkstar 

-----------------------------------------------------------------------
Bill Frantz        | Security is like Government  | Periwinkle
(408)356-8506      | services. The market doesn't | 16345 
Englewood Ave
www.pwpconsult.com | want to pay for them.        | Los Gatos, 
CA 95032

---

From: Derek Atkins <[email-masked]>
Date: Fri, 20 Mar 2015 12:13:20 -0400

> Well, the problem isn't the software. It is the user.

Bzzt.  I'm sorry, but when my software removes decryption algorithm
support it is most definitely NOT a user problem.  Requiring support for
multiple versions in parallel is also not a user problem.  But this has
moved way far off-topic for this list.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Derek Atkins <[email-masked]>
Date: Fri, 20 Mar 2015 12:15:06 -0400

Bill Frantz <[email-masked]> writes:

> The software works fine. The user has either lost the secret key file
> or has forgotten the passphrase. I don't know a technical solution,
> particularly to the 2nd problem. Any suggestions?

Nope, that's NOT the problem.  They keys all exist.  The passphrase is
known.  The problem is that software removed support for the
keys/algorithms in which the data is encrypted.  This is absolutely a
technical problem with the software and is completely solvable.

-derek

---

From: Andrew Skretvedt <[email-masked]>
Date: Sun, 22 Mar 2015 09:18:21 +0000

I am a curious onlooker with no operational affiliation to the business 
of this list (and normally silent), with an observation/question at this 
point in this thread:

Is it considered best practice now to encrypt, then sign? I think I 
heard somewhere that SSL/TLS does it the other-way-round and has thereby 
innocently created certain problems. GnuPG allows these operations to be 
combined on the command line, and then I don't know in what order they 
actually occur.

If you receive an encrypted and signed message, and best practice would 
be to, in reasonable time, decrypt from wire-format and re-encrypt to 
local format for PFS (which seems to me a really sound policy, given 
modern experiences, and might be just as easy as leaving it to your 
full-disk-encryption system where you store your mail), might you lose 
the ability to provably authenticate the messages in your archive? I can 
think of situations where one would not want to lose this ability (e.g. 
some sort of dispute or legal proceeding).

Perhaps if they get signed, then encrypted, this problem goes away. But 
then why /should/ one do these two operations in one order in the e-mail 
context, but perhaps the opposite order in others? (Perhaps I betray my 
ignorance at this point.)

---

From: ianG <[email-masked]>
Date: Mon, 23 Mar 2015 18:36:58 +0000

On 18/03/2015 22:38 pm, Bill Frantz wrote:
> The software works fine. The user has either lost the secret key file or
> has forgotten the passphrase. I don't know a technical solution,

Keystores like Apple's do fine here.  Basically, if we see the pgo key 
password as just one password in 100 then it becomes clearer.

Just another thing that made sense in 1992, but things have moved on ;)

iang

---

From: ianG <[email-masked]>
Date: Mon, 23 Mar 2015 19:03:59 +0000

On 22/03/2015 09:18 am, Andrew Skretvedt wrote:
> Is it considered best practice now to encrypt, then sign?

What is the meaning of 'sign'?  Do you mean here to sign as if you are 
affirming that it is you sending the message and you might consider this 
a digitial signature over your words?  If so, then you should sign 
before encryption, and it's a good idea to do that in cleartext/inline 
format.

Alternatively, are you signing to put a message authentication code over 
it so that it is securely delivered?  In which case, it is better 
practice to encrypt then sign.  While this is not a totally solid rule 
(it depends on the protocol details) I think this is safe in OpenPGP.

> I think I

Yeah, the research on attacking the order came after these things were 
thought about in groups.  But bear in mind there is a bit of a 
difference between SHA-style HMACs and RSA-style digsigs.

> some sort of dispute or legal proceeding).

Yes, that's complicated.  Suffice to say that the need to prove that you 
received a message and didn't change it is way-over-thought in the tech 
world.  99.999% of it is about having the message [1].  So let's solve 
the real problems before we make up problems...

> ignorance at this point.)

The reasons are historical.  Back then, nobody much knew the difference 
between authentication and signing.  Later on, HMACs were developed for 
the message integrity.  And signing-as-intent fell out of favour because 
nobody wanted it.

So likely a new message suite will include an AE or Authenticated 
Encryption suite, which will handle all the message integrity.  That'll 
be stripped off, and the message will be delivered plain.  Then the 
software will say who it comes from.  If there is a need to keep that 
proof then we'll likely need another tag to attach to the plaintext message.

iang

[1] as long as we're talking words.  If we're talking transactions then 
a common dispute is having different 'recollections' of the transaction, 
and having good MAC'd copies is what we want to achieve.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Mon, 23 Mar 2015 20:25:41 +0100

> But frankly I'd like my encryption software to just maintain the ability

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.