Re: [openpgp] Intent to deprecate: Insecure primitives

[Daniel Kahn Gillmor <[e-mail]>]

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.

On Fri 2015-03-13 21:22:34 -0400, David Leon Gil wrote:
> 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.

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

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

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

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,
> and is more malleable.)

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?

> 1. A published public key that is more than 1 year old. (This is
> 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
> using MD-5 or SHA-1.

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

     --dkg