DKIM, RFCs and Interpretations

28 May

I have been working on DKIM for the last couple of years and the journey has been very interesting.  Started with simple DKIM signing of mails and eventually spent considerable time on Signer Actions and Verifier Actions best practices. The later part is, to put it in a nutshell, an amazing experience.

If you live on the leading edge of any Internet technology that needs multi-vendor support and is cross-platform, you would know how critical the RFCs (http://www.ietf.org/rfc.html) turn out to be. As RFCs (and the respective consumers) evolve, the room for interpretation of the constructs in RFCs increase and you would see a lot of discussion around these interpretations.

Here is an example related to DKIM. For quite some time, all the DKIM signing entities are used to publishing public key records in the following format

“k=<proto>\; p=<pubkey>”

The above format is minimal and functional format for quite some time. For example, this is what gmail uses for this particular selector 20120113:

$ dig +short @ns1.google.com 20120113._domainkey.gmail.com txt
“k=rsa\; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1Kd87/UeJjenpabgbFwh+eBCsSTrqmwIYYvywlbhbqoo2DymndFkbjOVIPIldNs/m40KF+yzMn1skyoxcTUGCQs8g3FgD2Ap3ZB5DekAo5wMmk4wimDO+U8QzI3SD0” “7y2+07wlNWwIt8svnxgdxGkVbbhzY8i+RQ9DpSVpPbF7ykQxtKXkv/ahW3KjViiAH+ghvvIhkx4xYSIc9oSwVmAl5OctMEeWUwg8Istjqz8BZeTWbf41fbNhte7Y+YqZOwq1Sd0DbvYAD9NOZK9vlfuac0598HY+vtSBczUiKERHv1yRbcaQtZFh5wtiRrN04BLUTD21MycBX5jYchHjPY/wIDAQAB”

However, in the recent weeks, there is a growing set of ISPs that are mandating the other fields of a DKIM record. For example, RFC 5863 discusses DKIM verifier considerations in Appendix 1.2. The considerations around the DNS record talk about

If a DKIM verifier finds a selector record that has an empty “g” field (“g=;”) and it does not have a “v” field (“v=DKIM1;”) at its beginning, it is faced with deciding if this record was:

1. from a DK signer that transitioned to supporting DKIM but forgot to remove the “g” field (so that it could be used by both DK and DKIM verifiers); or

2. from a DKIM signer that truly meant to use the empty “g” field but forgot to put in the “v” field. It is advised that you treat such records using the first interpretation, and treat such records as if the signer did not have a “g” field in the record.

Looks like the notion of an empty “v” field is generating lot of noise from a few ISPs in the recent weeks. Even though the field is deemed optional, the interpretations by these ISPs have some ripple effects on how the other fields (like the granularity field) are seen in such situations.

Having read this RFC (and RFC 6376) a few times back and forth, it is time to test the DNS records by adding a  “v” field. I should be able to see the impact on those ISPs that changed their interpretations recently.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.