Re: [Dcrup] rsa-sha1 proposals

[Jim Fenton <[e-mail]>]

If it isn't obvious from my previous comments, I favor the "Deprecate
rsa-sha1" option. I might even suggest we soften it to say that
verifiers MUST implement rsa-sha256 and SHOULD implement rsa-sha1; it's
ultimately up to the verifier to decide what signatures they trust and
they might decide not to implement rsa-sha1 if they know they will never
accept one of those signatures anyway.

Having been away from this stuff for a while, I was startled that the
hash algorithms were named directly in the ABNF rather than by reference
to the registry, but that's what we do apparently. The description of
the rsa-sha1 algorithm (3.3.1 in RFC 6376) can be removed as well when
rsa-sha1 is removed entirely, of course.

-Jim

On 6/20/17 8:39 AM, Scott Kitterman wrote:
> 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
>
>
> _______________________________________________
> Dcrup mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dcrup