SHA-1 recommendations

[Daniel Kahn Gillmor]

On 05/17/2009 10:20 PM, David Shaw wrote:
> I would wager that IF an OpenPGP certification specific SHA-1 collision
> attack eventually appears, it would appear for photo IDs first.  There
> are a huge number of ways to twiddle bits in a JPEG (the thing supports
> *comment fields* for crying out loud) in ways that aren't visible in the
> image itself.

This does seem ripe for attack.

> Incidentally, I don't sign photo IDs.  It has nothing to do with this
> theoretical attack - a photo ID does not make a statement that I am
> willing to certify.

I've always assumed that a User Attribute of a jpeg is semantically
interpreted as a visual representation of the keyholder, by analogy to
the photo in a passport, driver's license, or other official
documentation.  It basically says "<so-and-so> looks like this:".  This
can change a fair amount (hair changes, age, accidents, body
modifications, odd lighting, etc make images far more fluid than UTF-8
name designations), so I can understand not being willing to make a
long-lived certification like this.  But i don't think it invalidates
the concept.

(as an aside, this does make me particularly wary of people who sign
photo IDs like the one attached to F1530A35)

> I do think that people should stop issuing SHA-1 certifications, but
> there are other considerations that need to be taken into account here -
> not all clients can handle those signatures, and I don't think we're at
> the point where defaults should be changed.  It's not a black or white
> situation.
>
> So, while I personally am issuing SHA-256 key certifications (and have
> been for a while), I do not think that switching the default away from
> SHA-1 is appropriate at this time.  What is good for me is not
> necessarily what is good for the whole world.

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.

Out of curiosity: how do you propose deciding when to change the default
certificate digest algorithm?  I understand that there are
interoperability concerns, many of which i'm personally less directly
affected by because of my involvement with the free software development
community, which tends to have a quicker (if not smoother) upgrade path.
 Can we characterize those concerns in some way to better understand
what needs to change in the broader landscape before the defaults get
changed?

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?  Is
there a way that we can make reasonable estimations for the same count
for GnuPG deployments?

Here's an idea: trawl the public keyservers, and look at the proportion
of valid (non-expired, non-revoked) keys with digest preference
subpackets in their self-sigs which mention any digest from the SHA-2
family.  It would be good to rule out abandoned keys somehow; doing so
is probably fundamentally impossible, but maybe we could approximate it
by discarding keys with no certifications attached in the last 5 years?

Are there better metrics?

> I see no conflict in the RFC:  the list is ordered, and a random
> selection is perfectly conformant.  The list is ordered to give
> implementations that want to do something useful with rankings something
> to work with (and note that both of the "big two" of PGP and GPG order
> their lists to varying degrees), but those implementations that do not
> want to play with rankings are allowed to pick however they like.  It's
> similar, in a way, to the IETF meta-rule: be conservative in what you
> generate, be liberal in what you accept.
> 
> So it's an ordered list of capabilities.  Or perhaps a capability set of
> preferences.  ;-)

I'm not suggesting there is a conflict in the RFC, simply that it seems
that GnuPG could use a refresh of its default digest preferences.  I'm
proposing (for new key generation):

 * include the stronger SHA-2 digests which gpg supports, and

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

I don't see how this could cause interoperability problems or violate
the RFC (as you say, other implementations are free to treat the list as
random), and it would help users of gpg communicate to each other
directly that they are happy to use the newer, stronger digests.  Are
there interop problems with doing this that i'm not aware of?  The only
thing i'd be worried about is if there are widespread implementations
which explicitly interpret the list as "preferential orderings,
*least*-desired first", but i don't think that's the case.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090518/d4ee1702/attachment.pgp>