Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt

[Scott Kitterman <[e-mail]>]

On Monday, June 12, 2017 01:54:57 PM Murray S. Kucherawy wrote:
> Hatless:
> 
> On Mon, Jun 12, 2017 at 7:41 AM, Martin Thomson <[e-mail]>
> 
> wrote:
> > On 12 June 2017 at 15:32, Scott Kitterman <[e-mail]> wrote:
> > > The way to do that would be to remove it from the protocol, which you
> > > seem to oppose, so I'm confused.
> > 
> > I don't oppose removing it from the protocol in practice, it's just
> > that you can't pretend that the old version doesn't exist, and nor
> > should you care.  The point is to not USE it, the definition becomes
> > harmless at that point.
> 
> +1.

I've thought about this some more.  And the more I think about it, the less I 
like it.

Here are the currently defined DKIM result names from the IANA Email 
Authentication Result Names registry[1]:

> dkim 	neutral 	[RFC7601] section 2.7.1 	active
> dkim 	none 	[RFC7601] section 2.7.1 	active
> dkim 	pass 	[RFC7601] section 2.7.1 	active
> dkim 	permerror 	[RFC7601] section 2.7.1 	active
> dkim 	policy 	[RFC7601] section 2.7.1 	active
> dkim 	temperror 	[RFC7601] section 2.7.1 	active

What's the proper result for a rsa-sha1 signed message that passes DKIM 
verification?  It's not 'none', because it's still a valid signature.  I hope 
it's not 'pass' since there's no way to communicate it should not be relied 
on.  If we really want to approach it this way, there needs to be a new 
result, something like pass-but-ignore (since downstream consumers will rely 
on a pass).

This seems like a horribly recipe for confused implementation for exactly no 
benefit.  If anyone is sending exclusively rsa-sha1 signed mail (I don't have 
access to a reasonable corpus to have an opinion on the rarity) they're 
ignoring a SHOULD NOT that dates back to the very first DKIM RFC a decade ago.

I would really appreciate it if someone in favor if keeping rsa-sha1 would 
describe, in detail, what the authentication-results header field is supposed 
to look like for this "it's valid DKIM, but don't rely on it" approach.

Scott K


[1] https://www.iana.org/assignments/email-auth/email-auth.xhtml#email-auth-result-names