Re: system-wide crypto policies
On Thu, June 27, 2013 22:16, Daniel Pocock wrote:
> On 27/06/13 21:44, Florian Weimer wrote:
>> * Daniel Pocock:
>>
>>> However, are such issues at the discretion of package maintainers and
>>> upstream, or is it useful to have a uniform Debian approach to
>>> cryptographic strength?
>>
>> Keep in mind that RFC 4880 (OpenPGP) hard-codes SHA-1 in several
>> places, notably for key fingerprints. If there's a uniform strength
>> requirement, we need some weasel words that GnuPG remains compliant.
>>
>> It's also unclear if SHA-256 or SHA-512 is stronger, and if either
>> really is that much better than SHA-1.
>
> Just to clarify, although my query was related to the use of this hash
> in GnuPG, the reason for the email on debian-devel is for the
> system-wide policy on hashes: which could mean any package (e.g. git
> uses SHA-1 too, some of the X.509 root certs use an SHA-1 hash)
>
> The first question then - do we even need to care, as a project, about
> being pro-active? Or just leave it at the discretion of derivatives and
> end-users to make their own policies? That's quite OK as long as this
> approach is documented. The security page[1] says "Debian takes
> security very seriously" and some users may ask how we apply that
> philosophy to SHA-1 given that it is on various alerts[2].
>
> It may be that we say "Some packages include SHA-1 technology and if the
> attack potential crosses some threshold X the security team will not
> support them." Then it is up to maintainers and upstreams to think
> about and start making plans for the future of their packages.
I think such decisions are indeed best left to individual package
maintainers as there's in my opinion no one sound advice that works for
all cases. While moving away from SHA-1 right now might make sense in some
cases, in others it's still problematic. You name X.509: CA roots are by
and large not moving away from SHA-1; you name GnuPG: SHA-1 is indeed in
the standard and signing stuff with non-SHA-1 hashes still leads to
compatibility issues which make that there's a good case for keeping the
current default.
Although deprecation is good, there's also still doubt on where to migrate
to. Per-package decisions are hence a much more suited approach than
archive-wide policies.
Cheers,
Thijs
Reply to: