Re: [Dcrup] rsa-sha1 proposals

I think we should go for removal.

I don't think implementation wise for receivers who have a choice, that
removal vs deprecation is going to have a big short-term impact, I doubt
most receivers would remove rsa-sha1 at the publish date or on the
deprecation date in the registry.  They'll assess the damage between
keeping it or removing it based on the current timeframes.

The larger question will be if implementations that others depend on start
removing it, ie if you upgrade your version of opendkim and rsa-sha1 is no
longer supported, you'll likely have unexpected changes to your receiving.
That said, I think that deprecation doesn't change the status quo enough.

Brandon

On Tue, Jun 20, 2017 at 12:00 PM, Kurt Andersen <kurta@drkurt.com> wrote:

>
>
> On Tue, Jun 20, 2017 at 8:39 AM, Scott Kitterman <sklist@kitterman.com>
> wrote:
>
>>
>> I think there are roughly three options that have been discussed:
>>
>> Status quo:
>>
>> > Signers MUST implement and SHOULD sign using rsa-sha256.  Verifiers MUST
>> > implement both rsa-sha1 and rsa-sha256.
>>
>> Deprecate rsa-sha1:
>>
>> > Signers MUST implement and sign using rsa-sha256 only.  Verifiers MUST
>> > implement both rsa-sha1 and rsa-sha256.
>>
>> Remove rsa-sha1:
>>
>> > Signers MUST implement and sign using rsa-sha256 only.  Verifiers MUST
>> > implement rsa-sha256.  rsa-sha1 is obsolete and MUST not be used.
>> Note: This option also removes rsa-sha1 from the ABNF.
>>
>
> [elided]
>
> Remove rsa-sha1:
>> This option eliminates (to the extent it is adopted) the potential of
>> security
>> risks with rsa-sha1.  .  .
>> While this might be considered somewhat abrupt, rsa-sha1 signing has been
>> effectively SHOULD NOT for a decade.  Maybe this will create some
>> momentum for
>> operators to move off of it.
>>
>> It is abrupt to remove something without a formal deprecation period.
>>
>
> I'm in favor of moving strongly and clearly to kill sha1, but what about
> moving it out to the registry with a dated "MUST NOT". That provides for a
> deprecation period without the need for further intervention. The other
> advantage is that it provides a stronger historical record that people can
> point to when explaining brain-deadness to people who have not updated :-)
> I would suggest a "drop dead" date of something like mid-2018 to allow the
> rest of this work to reach completion.
>
> --Kurt
>
> _______________________________________________
> Dcrup mailing list
> Dcrup@ietf.org
> https://www.ietf.org/mailman/listinfo/dcrup
>
>