Subject: Authentication-Results: changes

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Mar 2010 09:10:12 -0700

On Monday in the APPAREA meeting, I mentioned some upcoming work regarding the Authentication-Results: header field.  I've split the two changes I'm seeking to make into separate drafts because one is fairly trivial and only requires an IANA registration action to complete while the other touches a potentially complicated security issue, involves a format change, and thus probably involves a full spec revision.  So rather than hold up the simple one waiting for the complex one, I've split them.

One thing that was brought up way back in the early DKIM years, but dropped then as unimportant, was the idea that Authentication-Results needs a way to specify which signature a DKIM result is conveying.  Since more than one signature might be on a message from the same domain, we can't rely on "header.d" and "header.i" to be able to make this distinction.

For example: A message comes to you with two signatures, both from the signer. The only distinction is that one signature has an "l=" tag and one does not.  The message was altered by a mailing list.  Therefore, the signature with "l=" passes when you try it, and the other one fails.  You create a compliant Authentication-Results: header field to add to the message.  With the current specification, the best you can do is say "dkim=pass header.d=example.com; dkim=fail header.d=example.com" and perhaps rely on signature order to match them up.

I propose that we need a new tag, "header.b", which will contain the first several characters of the actual digital signature, which is pretty much guaranteed to be unique among signatures present.  This will allow unambiguous matching of signatures with results.

I have this now in a draft that I plan to move through the Applications area of the IETF as an individual submission since it's fairly minor:

http://datatracker.ietf.org/doc/draft-kucherawy-authres-header-b/

Comments welcome.

-MSK