Subject: Re: [ietf-dkim] Escaping things in key/ADSP records

From: Tony Hansen <[email-masked]>
Date: Sat, 01 Aug 2009 12:45:22 -0400

Jim Fenton wrote:
> If you still have the records, can you count the number of records
> with g=; ? That's used in an example in some of the DomainKey specs
> and works for DK but means "match nothing" for DKIM.

I was planning on doing an analysis of the key values anyway, so here goes.

65461 DNS _domainkey records were examined that did not contain syntax 
errors. Of these, 37309 were used by DKIM and 46623 were used by 
DomainKeys. (Some were used by both.) Of them, 2186 have v=DKIM1.

==== mistakes ====
As noted before, there were a number of mistakes found within the key 
records. I found occurrences of all of these
	DKIM=unknown	O=-		a=rsa-sha1
	c=nofws		c=relaxed/relaxed
	d=SOMEDOMAIN	dkim=all	i=*
	kv=DKIM1	o=-		o=~
	q=dns

If I trim the list down to the v=DKIM1 records, there are STILL errors:
	c=relaxed/relaxed	o=-

There are a few records that have r=EMAIL values in them.

==== legal keys ====

====== g= ======

The following valid g= values were used by DKIM:

	g=
	g=*
	g=noreply

For v=DKIM1 records, it's just

	g=*
	g=noreply

This confirms the suggestion a couple meetings ago that vendors should 
treat g= as equivalent to g=* if v=DKIM1 is not found.

There were NO cases of g=; found for v=DKIM1 records.

====== h= ======

The following valid h= values were used by DKIM. All of these were in 
v=DKIM1 records:

	h=sha1
	h=sha1:sha256
	h=sha256

A notable mistake was an entry with this value:
	h=rsa-sha1

====== k= ======

The following valid k= values were used by DKIM.

	k=rsa

A notable mistake was an entry with this value:

	k=rsa-sha1

It was NOT the same record as the similar h= mistake.

====== n= ======

1879 of the records used n=.

====== s= ======

The value
	s=email
was used in 33 records, 31 along with v=DKIM1.

====== t= ======

The following valid t= values were used by DKIM.

	t=s
	t=s:y
	t=y
	t=y:s

Of note are these two mistakes:
	t=n
	t=s|y

Hope people found this of interest.

	Tony Hansen
	[email-masked]
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Sun, 2 Aug 2009 18:33:52 -0700

On Jul 31, 2009, at 2:02 PM, Steve Atkins wrote:

> (This may be a duplicate, I have too many email addresses)
>
> On Jul 31, 2009, at 12:08 PM, Scott Kitterman wrote:
>
>> On Fri, 31 Jul 2009 10:19:43 -0400 Tony Hansen <[email-masked]> wrote:
>>> I'm wondering if there is a need for a web interface at dkim.org  
>>> that
>>> would validate someone's _domainkey TXT record.
>>>
>> I'd say yes.  It would provide a good way to isolate record  
>> specific issues
>> from other potential problems people are having error sources when
>> troubleshooting.
>
> I have some perl code that does some validation for internal use; it'd
> be fairly easy to turn it into a webapp.

http://dkimcore.org/tools/dkimrecordcheck.html

Given a selector and a domain it'll slurp the record from DNS.

Then it parses it, using the BNF from the spec (<rhetorical>why, oh,
why do we support FWS in a DNS record?</rhetorical>) and then
sanity checks the various fields and gives a good / bad message.

If anyone has good (or known bad) records that it gets wrong I'm
interested to hear about it.

Cheers,
   Steve

---

From: Tony Hansen <[email-masked]>
Date: Mon, 03 Aug 2009 05:20:37 -0400

Excellent job. Perhaps a pointer to this can go on the dkim.org site?

	Tony Hansen
	[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 3 Aug 2009 09:13:45 -0700

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Steve Atkins
> Sent: Sunday, August 02, 2009 6:34 PM
> To: DKIM WG
> Subject: Re: [ietf-dkim] Escaping things in key/ADSP records
> 
> [...]

> interested to hear about it.

It reports the contents of medusa3._domainkey.blackops.org as invalid which is not correct.  That record contains an "r=" and an "rs=" tag, both of which are defined by active I-Ds.  Those tags may be unknown to RFC4871, but that specification says such should merely be ignored; they don't render the record invalid.

-MSK

---

From: Steve Atkins <[email-masked]>
Date: Mon, 3 Aug 2009 09:58:55 -0700

On Aug 3, 2009, at 9:13 AM, Murray S. Kucherawy wrote:

> It reports the contents of medusa3._domainkey.blackops.org as  
> invalid which is not correct.  That record contains an "r=" and an  
> "rs=" tag, both of which are defined by active I-Ds.  Those tags may  
> be unknown to RFC4871, but that specification says such should  
> merely be ignored; they don't render the record invalid.

For typical DKIM users though, commenting on an invalid field as "This  
is probably invalid, but there might be an experimental I-D that's  
using it, so maybe it's OK and receivers may or may not ignore it" is  
going to be far more confusing than "This is wrong, fix it." - as if  
they're using "r=" it's probably a typo or a misunderstanding, rather  
than intentional use of an experimental field.

You're intentionally using non-standard or experimental fields - so  
you know better than the mechanical validator, and that's OK.

(If we were to add a form on dkim.org that points to the checker, that  
might be the place to discuss what it considers valid and what it  
doesn't.)

It might be interesting to have an alternate checker that tracks the  
additional fields being discussed in active I-Ds too, though. Is there  
a registry of experimental fields or list of I-Ds anywhere?

Cheers,
   Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 3 Aug 2009 10:28:42 -0700

> Sent: Monday, August 03, 2009 9:59 AM
> To: DKIM WG

How about: "The following tags are non-standard and will likely be ignored by most verifiers"?

Some of Tony's examples such as "h=rsa-sha1" can certainly be reported as "invalid" as they are standardized tags with illegal values (i.e., the legal values are enumerated).

> a registry of experimental fields or list of I-Ds anywhere?

Alas, no.  And it would be difficult, I think, to try to corral people into using one in general (though the audience is currently pretty small so for now it's a practical idea).

-MSK

---

From: Steve Atkins <[email-masked]>
Date: Mon, 3 Aug 2009 10:37:02 -0700

On Aug 3, 2009, at 10:28 AM, Murray S. Kucherawy wrote:
> Some of Tony's examples such as "h=rsa-sha1" can certainly be  
> reported as "invalid" as they are standardized tags with illegal  
> values (i.e., the legal values are enumerated).
>
> Alas, no.  And it would be difficult, I think, to try to corral  
> people into using one in general (though the audience is currently  
> pretty small so for now it's a practical idea).

Ah.

If there's no registry of fields then there's nothing to say that a  
receiver isn't experimenting with an r= field that's completely  
different to the r= field that Tony is publishing. So it isn't safe to  
assume that a receiver that isn't using Tony's definition of r= will  
ignore his r= field, rather we're solidly into undefined behavior and  
something that is definitely an error in a production record (as  
opposed to a record used for pre-arranged testing with a specific  
receiver).

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Mon, 03 Aug 2009 10:34:03 -0700

> It reports the contents of medusa3._domainkey.blackops.org as invalid which is not correct.  That record contains an "r=" and an "rs=" tag, both of which are defined by active I-Ds.  Those tags may…

An active I-D does not a standard make ;-)

But yeah, it should probably just tag them as unknown/ignored-by-4871 rather than an error.

Mike

---

From: Tony Hansen <[email-masked]>
Date: Mon, 03 Aug 2009 16:32:15 -0400

It could put in a heading of "Unrecognized tag X=" for each such tag.

	Tony Hansen
	[email-masked]