[Dcrup] rsa-sha1 proposals

[Scott Kitterman <[e-mail]>]

I think we still have some different opinions on what to do with rsa-sha1, so 
I thought I'd attempt to summarize the different options (as best I can, I 
have an opinion, so I'm sure my bias will leak in) in the hopes it will help 
drive this part of the WG discussion to closure.  Note: I'm not talking about 
RSA key sizes because it seems to me we're largely converged on that topic.

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.

Pro/Con for each:

Status quo:
There is no immediate known security threat to rsa-sha1 that would indicate 
its imminent demise as a useful algorithm in this application and rsa-sha1 
signatures are still in significant use.  RSA key sizes are the current 
security issue and that can be fixed without doing anything about rsa-sha1.

There are a number of known shortcomings with rsa-sha1 and given that rsa-
sha256 is available and does not share the same issues, raising the bar to 
require rsa-sha256 is easy and a prudent step to take in advance of issues 
being published.  Let's not wait until we have to panic.

Retaining rsa-sha1 means DKIM implementers will have to deal with three 
algorithms rather than two and this raises implementation complexity and the 
risk of things going wrong.


Deprecate rsa-sha1:
There is no immediate known security threat to rsa-sha1 that would indicate 
its imminent demise as a useful algorithm in this application and rsa-sha1 
signatures are still in significant use.  RSA key sizes are the current 
security issue and that can be fixed without doing anything about rsa-sha1, 
but if we move to a more aggressive stance against rsa-sha1 now, it should be 
easier to remove it when needed.

There are a number of known shortcomings with rsa-sha1 and given that rsa-
sha256 is available and does not share the same issues, raising the bar to 
require rsa-sha256 is easy and a prudent step to take in advance of issues 
being published.  Let's not wait until we have to panic.

Retaining rsa-sha1 means DKIM implementers will have to deal with three 
algorithms rather than two and this raises implementation complexity and the 
risk of things going wrong.

Remove rsa-sha1:
This option eliminates (to the extent it is adopted) the potential of security 
risks with rsa-sha1.  If a relevant issue with rsa-sha1 is made public, there 
will be no further standards work that needs to be done.  This option also 
keeps the number of algorithms at two, eliminating the additional complexity 
associated with having more algorithms to sort through in implementation.  
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.

Thoughts?

Scott K