SHA-1 recommendations

[Robert J. Hansen]

Daniel Kahn Gillmor wrote:
> Understood.  We're not discussing changing the defaults here, though,
> we're discussing Robert J. Hansen's proposed document for people who are
> interested in mitigating whatever risks may be implied by a progressive
> weakening of SHA-1.

Please; in conversation, I'm just Rob.  I have an unfortunate name, in
that it's shared by a lot of famous people: Robert Hansen the serial
killer, Robert Hanssen the Soviet spy, Robert Hansen the NBA All-Star,
Robert Hansen the CEO of SecTheory... to make matters worse, I have
tangential connections with almost all of them.  I grew up near to where
Robert Hansen the serial killer grew up, I was active on a couple of the
same USENET groups as Robert Hanssen the spy, I attended the same
college as Robert Hansen the NBA All-Star, both SecTheory Robert Hansen
and I have spoken at some of the same conferences, etc., etc.

Basically, if I don't go by my full name and middle initial, I tend to
walk into identity misunderstandings that are straight out of _Twelfth
Night_.

> Can we characterize those concerns in some way to better understand
> what needs to change in the broader landscape before the defaults get
> changed?

My own number one: PGP 6 needs to be abandoned.  It's old, it's not
especially standards-conformant (not surprising, given it predates the
standard), and cert-digest-algo will break it.  As will any hashes other
than SHA-1, MD5 and RIPEMD160, for that matter.

The installed base of PGP 6 users is immense, and many of them staunchly
refuse to upgrade.  So if we shift to SHA256 across the board, a lot of
PGP 6 users will scream bloody murder that we're breaking traffic for them.

OpenPGP has always been hobbled by its own success.  The number one
inhibitor of OpenPGP adoption has always been the tremendous success of
PGP 2.6, which is still in use in lots of places.  Once you come up with
something that works and works well, you create tremendous inertia which
resists the adoption of something new -- even if that something new is
necessary.

> Should we ask PGP Corp (and any other vendors on ietf-openpgp) for their
> deployment estimates of PGP versions which do not support SHA-256?

We could, but I don't think it would be productive.  SHA256 has been
supported since PGP 8, which is by this time more than a few years old.
 PGP 6 goes back all the way to, what, '97 -- people who are installing
PGP 6 nowadays are doing it by getting copies from their friends, not by
downloading it from PGP Corporation.

AFAIK, PGP Corporation no longer makes PGP 6 available for download, and
would much rather it just went away.  They get to deal with the headache
of the installed PGP 6 userbase just like we do.

>  * re-order them in a clearly-stated way (i.e. commit to saying "gpg
> interprets and produces the orderings as preferential, with most-desired
> first"), and explicitly, publically prefer digests from the SHA-2 family
> over SHA-1.

This would require a modification to the current code, which I would
feel kind of bad about.  I harped on the importance of considering the
recipient's preferences for quite a while; finally, David was kind
enough to change algorithm selection so that it works by a modified
Borda count.  We'd have to revisit that code, but I don't see as how it
would be too difficult.  I'd offer a patch, but I don't know what the
GnuPG project's policy is on this -- some GNU projects frown on it for
reasons of the headaches associated with copyright assignment.